Re: Page fault from linux_proc_exit()
On Wed, Sep 18, 2013 at 12:14:04AM +0400, Vagner wrote: > Hi! > I ran skype and perhaps, it was *destroyed* (may be it was fault of skype > , I don't know). After I have got system panic. I looked to coredump: > - I got fault in frame #7 where: if ((q->p_flag & P_WEXIT) == 0 && > em->pdeath_signal != 0). But struct linux_emuldata *em == NULL. > > # from kgdb: > # p em > # $1 = (struct linux_emuldata *) 0x0 > > - I saw what `em = em_find(q, EMUL_DOLOCK);' from upper line of code > and from function em_find() that `em' could be equal NULL. > > Perhaps, are we need to add check after line call em_find in function > linux_proc_exit() - `continue;`? > In general this is a race condition and linux_proc_exit is not the only place where this is a problem. see http://people.freebsd.org/~mjg/patches/linux-emuldata-race-hack.diff Maybe I'll get around to commit this during the weekend, I am happy to let someone else work on this though. -- Mateusz Guzik ___ 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: Should process run under chroot(8) still see mounts on the original system?
On Tue, Jul 23, 2013 at 04:44:18PM -0700, Yuri wrote: > On 07/23/2013 16:31, Mateusz Guzik wrote: > >Of course then you may have some unnecessary separation but that I > >believe can be simply worked out if it turns out to be problematic. > > > jail would completely separate two systems. In my case this app also > communicates through files that it creates and host app reads > through symbolic links. It might also be assuming that it runs on > the same host and maybe is unable to connect to X server other than > through the shared memory. > 1. fs level cooperation is not going to be affected in any way. for all practical purposes you can assume fs-wise jail is a chroot with ".." escape disabled 2. typically local applications connect to X server over unix socket, i.e. something you would have to expose in the jail anyway (by e.g. mount -t nullfs /tmp /path/to/jail/tmp) Of course I can be wrong here, but looks like jail is a drop-in replacement here. -- Mateusz Guzik ___ 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: Should process run under chroot(8) still see mounts on the original system?
On Tue, Jul 23, 2013 at 04:17:02PM -0700, Yuri wrote: > Currently, mount directories as shown by mount(8) command and > /compat/linux/dev/mounts from linprocfs(5) still show the original > mount points as other non-chrooted processes see. > So, when some program run under chroot tries to read the mount > points and do something with them it would likely fail because those > paths aren't what the process actually sees in its file system. > > There are two situations: one when the process was started already > chrooted (like with command chroot(8)), and another one is when > process calls chroot(2) itself. Currently system seems to not > differentiate between these two cases. > > It looks reasonable to automatically modify mount(8) and > linprocfs(5) results when the process has been started already > chrooted and this process is (practically) always unaware of chroot. > So that when chroot was in place when execve(2), kernel could set > the boolean flag and later adjust mount directories accordingly. > While changing the code to do what you propose would not be that difficult, I don't see the point. In cases like this you can simply jail(2) and there you go (or at least this should work just fine). Of course then you may have some unnecessary separation but that I believe can be simply worked out if it turns out to be problematic. -- Mateusz Guzik ___ 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: signal vs. sigaction and SIGCHLD
On Thu, May 23, 2013 at 08:48:28AM +1000, Noel Hunt wrote:
> I have a small test program which simply forks and execs
> its command line arguments, but after the fork and before
> the exec, it sends a SIGSTOP to the child. The parent then
> sleeps for 3 seconds before exiting. However, a signal
> handler for SIGCHLD has been installed and I was expecting
> the parent to be notified of the SIGSTOP sent to the child,
> but with the `signal' interface this doesn't appear to work.
>
> If I change the code to use `sigaction' and `sigprocmask'
> (to unblock any blocked SIGCHLD), this program works the
> way intended, that is, the signal handler is called:
>
> 12 static void waithandler(int i){
> 13 int pid, cursig;
> 14 int tstat;
> 15
> 16 #ifdef SIGACTION
> 17 pid = waitpid(-1, &tstat, WUNTRACED);
> 18 #else
> 19 pid = wait(&tstat);
> 20 signal(SIGCHLD, waithandler);
You wait differently in case both cases. wait(2) waits for any child to
exit, which clearly is not happening here. If you perform the same
waitpid in both cases it should work fine.
> If I recompile with `#undef SIGACTION', waithandler is not
> called.
>
As noted earlier it is called. You can easly check that by printfing
something at the beginning.
> I should add that even with the sigaction(2) interface, without
> the `sigprocmask' call, it still doesn't work, which suggests
> that SIGCHLD is being blocked.
>
It could be that inherited signal mask blocks it.
--
Mateusz Guzik
___
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: syscall to userland interface
On Sat, May 11, 2013 at 09:23:31AM +0100, Karl Dreger wrote: > What my question boils down to is this: when running fork and friends > > from userland they are invoked as: > > fork();, open();, read();, close(); ... > > > but are defined as: > > sys_fork(), sys_open(), sys_read(), sys_close(), ... > > in their actual c definition. sys_* are symbols visible only in the kernel, and as such their names or existence is not visible from userspace. The kernel has syscall table - each syscall has an entry in the table at specified offset (syscall number) with a pointer to function implementing given syscall. Userspace knows syscall numbers. So the common thing for both userspace and kernel is syscall number, it has nothing to do with names. Here is an example how syscall worked on i386: - you put syscall numer in eax register - you call the kernel by issuing int 80h - handler in the kernel takes number from eax, looks up appropriate function from syscall table and calls that function Here is an example: http://www.freebsd.org/doc/en/books/developers-handbook/x86-system-calls.html e.g. fork has number 2. So, what userspace fork function does is simply telling the kernel to execute syscall number 2. It is not important how function implementing this syscall is named, it could be "foobarbecausewhynot". I hope this clears things up. -- Mateusz Guzik ___ 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: old style kernel configuration
On Sun, Nov 25, 2012 at 11:28:48AM +0100, Jeremie Le Hen wrote: > Hi! > > On Thu, Nov 22, 2012 at 05:38:58PM +0100, Mateusz Guzik wrote: > > > > # make buildkernel ... KERNFAST=1 > > Is it documented somewhere? I was using NO_CLEAN=1. > Yep, build(7). -- Mateusz Guzik ___ 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: old style kernel configuration
On Thu, Nov 22, 2012 at 11:35:57AM -0500, Zaphod Beeblebrox wrote: > On Wed, Nov 21, 2012 at 8:58 PM, Eitan Adler wrote: > > I've been working on removing obsolete information various documents. > > While going through older articles I noticed a few references to the > > "old style" kernel configuration involving running config(1) manually. > > > > Is there any value in keeping this documented as an alternative to > > "make buildkernel" or should it be treated as an implementation detail? > > I suppose it makes less difference on a modern system where "make > buildkernel" takes 15 minutes or even less, but the manual kernel > build gives the opportunity to rebuild a kernel without building > everything --- as in the case where you just modified something simple > (say USB or PCI device IDs). I'm not talking about the dedicate > kernel developer who should "know things" like this, but the user who > makes these kernel modifications occasionally. # make buildkernel ... KERNFAST=1 -- Mateusz Guzik ___ 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: Pull in upstream before 9.1 code freeze?
On Thu, Jul 05, 2012 at 12:03:21PM +0200, Olivier Smedts wrote: > 2012/7/5 Doug Barton : > > On 07/04/2012 15:01, Mike Meyer wrote: > >> On Wed, 04 Jul 2012 14:19:38 -0700 > >> Doug Barton wrote: > >>> On 07/04/2012 11:51, Jason Hellenthal wrote: > >>>> What would be really nice here is a command wrapper hooked into the > >>>> shell so that when you type a command and it does not exist it presents > >>>> you with a question for suggestions to install somewhat like Fedora has > >>>> done. > >>> I would also like to see this feature, which is pretty much universal in > >>> linux at this point. It's very handy. > >> > >> I, on the other hand, count it as one of the many features of Linux > >> that make me use FreeBSD. > > > > First, I agree that being able to turn it off should be possible. But I > > can't help being curious ... why would you *not* want a feature that > > tells you what to install if you type a command that doesn't exist on > > the system? > > You mean, this desktop "dumb mode" thing that makes my hard drive led > crazy-blink and makes me hit (first) my desk and (then) ^C before > anything is displayed ? > > my FreeBSD desktop : > % time dsfsd > dsfsd: Commande introuvable. > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w > > an Ubuntu "server" : > # time fsqfqsdfs > fsqfqsdfs: command not found > > real0m0.408s > user0m0.120s > sys 0m0.040s > > and that's a *fast* one ! > I'd like to point out that the idea is to give the user an easy way obtain package name for given potentialy missing program that is presented to him on error. It doesn't require spitting the list on every occasion and thus introducing overhead. One can just implement a standalone script that does package/port search and add a hook to the shell that prints the following: Command foo not found. Run pkg whatever foo to obtain list of ports/packages providing this program. No overhead, the message is not too long and can be disabled if someone finds it offensive. Does this sound reasonable? -- Mateusz Guzik ___ 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: reason for "magic" crashes.
On Sun, Jun 24, 2012 at 08:50:41PM +0200, Wojciech Puchar wrote: > >> > >> > >>There is nothing in cron that is done at sunday. > >> > >>i don't run "periodic" stuff in /etc/crontab > >> > > > >Compile the kernel with the following: > > > >makeoptions DEBUG="-O0 -g" > > > >options KDB # Enable kernel debugger support. > >options DDB # Support DDB. > >options GDB # Support remote GDB. > >options DEADLKRES # Enable the deadlock resolver > >options INVARIANTS # Enable calls of extra sanity > >checking > >options INVARIANT_SUPPORT # Extra sanity checks of internal > >structures, required by INVARIANTS > >options WITNESS # Enable checks to detect deadlocks > >and cycles > >options WITNESS_SKIPSPIN# Don't run witness on spinlocks for > >speed > >options DIAGNOSTIC > > > >After kernel panic ddb prompt will be waiting for you. Type in: > >dump > >reset > > > >Make sure you have swap that can handle crashdumps. > > already did this part and debug part, but not DDB. As you see - hang > not crashdump > > how much would it slow down whole thing? > > If less than 2 times it can be - CPU are rerely half loaded Are you asking about overhead of DDB or all debug options? I don't think that DDB support can be accounted for slowdown. As for the rest, it's hard to say. I guess it depends on your workload, also I never performed any benchmarks to compare this and I'm unaware of any. In other words, you have to test it yourself. -- Mateusz Guzik ___ 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: reason for "magic" crashes.
On Sun, Jun 24, 2012 at 07:05:35PM +0200, Wojciech Puchar wrote: > i've got third crash third week in a row. > > Every time in sunday after 18:00, every time with rsync process > (which means rsync based backup that is done every day, not just in > sunday!), > > you may see a crash (viewed from KVM) at > > http://www.tensor.gdynia.pl/~wojtek/crash.png > > what is important - syncing disk doesn't go on, system hangs here. > > For 99% system is not overheating at sunday, but i will be 100% sure > as i added ipmitool sensor logged from cron every 5 minutes. > > Please give me an idea what to check. > > > There is nothing in cron that is done at sunday. > > i don't run "periodic" stuff in /etc/crontab > Compile the kernel with the following: makeoptions DEBUG="-O0 -g" options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed options DIAGNOSTIC After kernel panic ddb prompt will be waiting for you. Type in: dump reset Make sure you have swap that can handle crashdumps. See this for more details: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html You can check if everything works correctly by issuing panic manually: sysctl debug.kdb.panic=1 then typing aforementioned ddb commands. After reboot you should get core in /var/crash. Also provide the following: - system version - filesystems involved in rsync with mount details (e.g. UFS with SU+J) - dmesg Hopefully this will be enough for someone to help. -- Mateusz Guzik ___ 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: [jail] Allowing root privledged users to renice
On Fri, May 25, 2012 at 10:23:53AM -0700, Julian Elischer wrote: > On 5/25/12 10:04 AM, Bjoern A. Zeeb wrote: > >On 25. May 2012, at 16:48 , Sean Bruno wrote: > > > >>I've been toying with the idea of letting jails renice processes ... how > >>dangerous and/or stupid is this idea? > >> > >> //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 - > >>/home/seanbru/ybsd_9/src/sys/kern/kern_jail.c > >>270a271,275 > >>+ int jail_allow_renice = 0; > >>+ SYSCTL_INT(_security_jail, OID_AUTO, allow_renice, CTLFLAG_RW, > >>+&jail_allow_renice, 0, > >>+"Prison root can renice processes"); > >> > >>3857a3863,3865 > >>+ case PRIV_SCHED_SETPRIORITY: > >>+ if (!jail_allow_renice) > >>+ return (EPERM); > > > >I think sysctls are a bad idea given jails have per-jail flags these days. > > > >Maybe also only allow re-nicing to be nicer but not less nice? > for sure ! start a jail with it's max priority and the > root within can allow nicer priorities only.. > you can always add priority from teh master (parent) environment outside. > Unless I seriously misunderstood something, that's the case right now. That is, PRIV_SCHED_SETPRIORITY matters only if resulting nice parameter would be lower. -- Mateusz Guzik ___ 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: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote:
> Quoting Mateusz Guzik :
>
> >On Wed, May 16, 2012 at 12:30:20AM +0300, tza...@it.teithe.gr wrote:
> >>Hello Community,
> >>
> >>I have the project "Automated Kernel Crash Reporting System" for
> >>this GSoC and I would like to discuss my plans about it before
> >>starting the coding on May 21.
> >>
> >
> >Cogratulations. :)
> >
> >>I have created a page in the FreeBSD Wiki
> >>(http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem)
> >>where I describe in details the architecture of the system.
> >>
> >>Here are some points that I would like to be discussed:
> >>
> >>* The implementation of the kcrashreporter is planned to be done in
> >>two shell scripts. The first shell script is a rc.d script and the
> >>second is the actual program. I choose to code it in shell because
> >>kcrashreporter invokes the kgdb to collect the necessary debugging
> >>information. I think that using the shell instead of traditional
> >>programming language for this kind of job is more straightforward
> >>and natural. Do you have a different opinion?
> >>
> >
> >Are you going to support textdumps?
> >
> >I would like to note that some machines have swap space only for
> >textdumps, so I think you should support these.
>
> Support for textdumps is already on the list.
>
> >ddb is equiped with a lot of cool commands that show various important
> >debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such
> >facilities so you will have to implement those first if you decide to
> >use it (btw I think these would be useful even without this project).
> >Take a look at tools/debugscripts.
> >That being said, I would give a priority to support for textdumps (and
> >in case kgdb support cannot be finished in time, I would make sure that
> >the project is expendable enough to support information obtained from
> >kgdb and possibly other sources).
>
> Indeed, DDB is equipped with features that kgdb does not provide but
> only kgdb has access to the full debug information whenever we want
> because of its operation on the core dump. As far as I understand,
> if we want to use DDB to collect the debugging information, we have
> to do it *immediately* after the kernel panic and before the first
> reboot. Also consider that DDB is not included in the generic
> FreeBSD kernel of -STABLE and -RELEASE. You have to compile a custom
> kernel with the options KDB and DDB. I think that the nature of DDB
> as an on-line debugger is a restriction mainly for the manual
> behavior of kcrashreporter.
Maybe this is a gross misunderstanting on my side, but I'm pretty sure
that:
DDB supports simple form of scripting that allows series of commands to
be run on certain events, e.g. kernel panic. Output can be captured
("capture on").
textdump is a part of DDB that saves aforementioned output.
In other words, there are no textdumps without DDB and there is no
problem with running DDB commands automatically after panic. Also it
looks like you will have to actually add DDB to GENERIC in order to obtain
textdumps in default installations.
> I do not think that I could update the kgdb with the features that
> DDB provides, but if it is mandatory to collect these information
> and kgdb cannot, I will do my best.
>
> >I don't know if these are good ideas (no clue about cryptography), but I
> >would either:
> >- HTTP POST data over SSL
> >or
> >- HTTP POST data encrypted with some public key
>
> Nice. What about curl over the HTTPS protocol?
>
curl would be ok, except it's not in the base system.
Actually I just now checked for tools in base that support HTTP POST and
couldn't find any. Should've checked before proposing such solution,
sorry.
> >hardware information, dmesg, locks, locked vnodes, mount points, ps,
> >backtraces of all threads
> >
> >Basically if ddb can show something easly enough (or you will be able to
> >make it do so), the report should contain it.
>
> First I will try to search if and how we can obtain these
> information using kgdb.
>
>
> >I guess this site won't be very busy, so whatever popular httpd you will
> >choose it should be fine (although I would stick with either apache or
> >nginx). No clue about databases.
>
> One more vote for nginx.
>
> >Also it would be nice to have a way to contact the owner of machine that
> >submitted the report. One way I can think of is the ability to specify
> &g
Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On Wed, May 16, 2012 at 12:30:20AM +0300, tza...@it.teithe.gr wrote: > Hello Community, > > I have the project "Automated Kernel Crash Reporting System" for > this GSoC and I would like to discuss my plans about it before > starting the coding on May 21. > Cogratulations. :) > I have created a page in the FreeBSD Wiki > (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) > where I describe in details the architecture of the system. > > Here are some points that I would like to be discussed: > > * The implementation of the kcrashreporter is planned to be done in > two shell scripts. The first shell script is a rc.d script and the > second is the actual program. I choose to code it in shell because > kcrashreporter invokes the kgdb to collect the necessary debugging > information. I think that using the shell instead of traditional > programming language for this kind of job is more straightforward > and natural. Do you have a different opinion? > Are you going to support textdumps? I would like to note that some machines have swap space only for textdumps, so I think you should support these. ddb is equiped with a lot of cool commands that show various important debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such facilities so you will have to implement those first if you decide to use it (btw I think these would be useful even without this project). Take a look at tools/debugscripts. That being said, I would give a priority to support for textdumps (and in case kgdb support cannot be finished in time, I would make sure that the project is expendable enough to support information obtained from kgdb and possibly other sources). > * Can you recommend a secure way of sending a report from a FreeBSD > system to the Central Collector machine? > I don't know if these are good ideas (no clue about cryptography), but I would either: - HTTP POST data over SSL or - HTTP POST data encrypted with some public key > * Which data do you want kcrashreporter to collect? At the moment I > have considered the panic message, the backtrace, the version level > of the release, the hardware platform (uname -vm) and the > configuration file of the panicked kernel (config -x `sysctl -n > kern.bootfile`). > hardware information, dmesg, locks, locked vnodes, mount points, ps, backtraces of all threads Basically if ddb can show something easly enough (or you will be able to make it do so), the report should contain it. > * Do you propose a different Web Server than the Apache HTTP Server? > For example, on my initial planning I had included MySQL as the > selected DBMS and after some discussions I changed to PostgreSQL. > I guess this site won't be very busy, so whatever popular httpd you will choose it should be fine (although I would stick with either apache or nginx). No clue about databases. Also it would be nice to have a way to contact the owner of machine that submitted the report. One way I can think of is the ability to specify e-mail address (say in rc.conf?) that will be included in the report. -- Mateusz Guzik ___ 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"
[patch] kqueue support for /dev/klog
Hello, one pr ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156423 ) contains request to add kqueue support to /dev/klog. Assuming that this is a desirable feature, how about this patch (based on audit pipe's code): http://student.agh.edu.pl/~mjguzik/patches/dev_klog-kqueue.patch Tested with this trivial program: http://student.agh.edu.pl/~mjguzik/kqread.c Thanks, -- Mateusz Guzik ___ 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: Why I can't trace linux process's childs with truss?
On Sun, Sep 12, 2010 at 3:08 PM, Alexander Best wrote: > there's a PR related to this "issue" [1]. so is truss missing this > functionality or is this in fact a feature, because truss musn't be used on > any non freebsd executable? > Actually truss handles linux processes just fine, except for their children. :) Linux process can create a child using linux_clone syscall, but truss does not handle that case and this can be the problem that Yuri reported (since no log was provided, I can only guess). This trivial patch should fix this: http://student.agh.edu.pl/~mjguzik/truss-linux-forks.patch Tested on this simple program: http://student.agh.edu.pl/~mjguzik/fork.c If it still does not work, log generated by truss would be helfpul. Regards, -- Mateusz Guzik ___ 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: panic by unlocking of mutex in KLD
On Mon, Jan 12, 2009 at 08:49:59PM +0100, Alexej Sokolov wrote:
> 2009/1/12 Mateusz Guzik
>
> > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote:
> > > 2009/1/12 Mateusz Guzik
> > >
> > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote:
> > > > > 2009/1/12 Mateusz Guzik
> > > > > > Mutexes have owners. It panics on loading because processes cannot
> > > > > > return to userland with locks held.
> > > > >
> > > > > i am not sure about it. Some time ago i implemented a charecter
> > device
> > > > with
> > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock
> > it.
> > > > The
> > > > > user space programm opens device, then mekes "write" (mutex will held
> > in
> > > > > kernel), goes back to user space, then makes "read" (mutex will
> > unlocked
> > > > in
> > > > > kernel) and it all run without panic. If needed i can post the source
> > > > code.
> > > > >
> > > >
> > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the
> > > > kernel panicked like this (while loading your module):
> > > >
> > > > System call kldload returning with 1 locks held
> > >
> > > My kernel is compiled without WITNESS. And it allows to lock mutex in one
> > > systcall (for example "write") and to unlock it in other ("read").
> > > Do you mean it is "very bad idea" to do something like this ?
> > > I could not find anywhere in the documentation that a it is not allowed
> > to
> > > return in the user space with a locked mutex.
> > > Can you give me some reference on man page, source code or something
> > other
> > > from where can I understand it ?
> > >
> >
> > Locks are used to synchronize access to data changeable by other
> > threads. I don't know if I'm correct here, but let's consider the
> > following situation: your process grabs a mutex and returns to userland,
> > then it's killed due to segmentation violation. This mutex should (and
> > can be) unlocked on exit, but the state of data protected by it is
> > unknown. (For example your process was killed while inserting something
> > into linked list.) So even if the kernel could be guided to unlock it on
> > exit, the data could be in inconsistent state.
> >
> > Also your locking scheme doesn't make much sense. Consider this:
> >proc1 calls write on your cdev
> > but in the meantime
> >proc2 calls read on your cdev
> >
> > So you get panic because proc1 was writing some data. (attempt to unlock
> > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would
> > read inconsistend data because proc1 was writing. Proper solution is to
> > lock mutex before and after reading/writing data. For working example
> > you can check how devctl was implemented (sys/kern/subr_bus.c).
> >
> > --
> > Mateusz Guzik
> >
>
> Ok , now I understaand it.
> If a thread return to user space with locked mutex, kernel doesen't know if
> the thread will come back to unlock it. It is really unsafe return to
> userspace without unlocking of helding mutexes.
>
Provided example is really unfortunate. :/ Forget it.
(And a proper solution for your locking issue is of course to lock
mutex before read/write and *unlock* it after it's done. (missed that
word in my previous mail))
Threads in userland holding kernel locks would lead to panics in a lot
of situations. For example you already have sleepable mutex and call
some kernel function that acquires sx lock - the kernel panics as this
is not allowed combination.
--
Mateusz Guzik
___
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: panic by unlocking of mutex in KLD
On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote:
> 2009/1/12 Mateusz Guzik
>
> > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote:
> > > 2009/1/12 Mateusz Guzik
> > > > Mutexes have owners. It panics on loading because processes cannot
> > > > return to userland with locks held.
> > >
> > > i am not sure about it. Some time ago i implemented a charecter device
> > with
> > > two syscalls: write, read. "write" lock the mutex and "read" unlock it.
> > The
> > > user space programm opens device, then mekes "write" (mutex will held in
> > > kernel), goes back to user space, then makes "read" (mutex will unlocked
> > in
> > > kernel) and it all run without panic. If needed i can post the source
> > code.
> > >
> >
> > Do you have kernel compiled with WITNESS? At least on -CURRENT the
> > kernel panicked like this (while loading your module):
> >
> > System call kldload returning with 1 locks held
>
> My kernel is compiled without WITNESS. And it allows to lock mutex in one
> systcall (for example "write") and to unlock it in other ("read").
> Do you mean it is "very bad idea" to do something like this ?
> I could not find anywhere in the documentation that a it is not allowed to
> return in the user space with a locked mutex.
> Can you give me some reference on man page, source code or something other
> from where can I understand it ?
>
Locks are used to synchronize access to data changeable by other
threads. I don't know if I'm correct here, but let's consider the
following situation: your process grabs a mutex and returns to userland,
then it's killed due to segmentation violation. This mutex should (and
can be) unlocked on exit, but the state of data protected by it is
unknown. (For example your process was killed while inserting something
into linked list.) So even if the kernel could be guided to unlock it on
exit, the data could be in inconsistent state.
Also your locking scheme doesn't make much sense. Consider this:
proc1 calls write on your cdev
but in the meantime
proc2 calls read on your cdev
So you get panic because proc1 was writing some data. (attempt to unlock
mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would
read inconsistend data because proc1 was writing. Proper solution is to
lock mutex before and after reading/writing data. For working example
you can check how devctl was implemented (sys/kern/subr_bus.c).
--
Mateusz Guzik
___
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: panic by unlocking of mutex in KLD
On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > Mutexes have owners. It panics on loading because processes cannot > > return to userland with locks held. > > i am not sure about it. Some time ago i implemented a charecter device with > two syscalls: write, read. "write" lock the mutex and "read" unlock it. The > user space programm opens device, then mekes "write" (mutex will held in > kernel), goes back to user space, then makes "read" (mutex will unlocked in > kernel) and it all run without panic. If needed i can post the source code. > Do you have kernel compiled with WITNESS? At least on -CURRENT the kernel panicked like this (while loading your module): System call kldload returning with 1 locks held -- Mateusz Guzik ___ 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: panic by unlocking of mutex in KLD
On Mon, Jan 12, 2009 at 02:47:26PM +0100, Alexej Sokolov wrote:
> Hello,
>
> by unloading of folowing module I have kernel panic.
>
> I would like to get any explanation about my mistake.
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
>
> struct mtx my_mtx;
>
>
> /* Load handler */
> static int
> load(struct module *mod, int cmd, void *arg)
> {
> int error = 0;
> switch(cmd) {
> case MOD_LOAD:
> printf("Start! Addres of mutex = 0x%X \n",
> &my_mtx);
> mtx_init(&my_mtx, "My mutex name", "My mutex
> type", MTX_DEF);
>
> mtx_lock(&my_mtx);
> break;
> case MOD_UNLOAD:
> printf("Stop! Addres of mutex = 0x%X \n",
> &my_mtx);
> mtx_unlock(&my_mtx);
> break;
> default:
> error = EOPNOTSUPP;
> break;
> }
>
> return (error);
> }
>
> /* Module structure */
> static moduledata_t mod_data = {
> "mymod",
> load,
> NULL
> };
> MODULE_VERSION (kld, 1);
> DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE);
>
>
Acutally it panics even on loading. :)
Mutexes have owners. It panics on loading because processes cannot
return to userland with locks held. It panics on unloading (in your
case) because curproc != my_mtx's owner.
--
Mateusz Guzik
___
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: "/var/log/messages" logs appear in the output of "sysctl -a"
On Wed, Jan 07, 2009 at 01:30:20PM +0200, Eitan Shefi wrote: > I am testing a NIC driver. > I found it's logs and "/var/log/messages" logs in the output of "sysctl > -a": > I run "sysctl -a | less", and there I find: > [..] > kern.msgbuf: ound file system checks in 60 seconds. > <118> > mtnic0: FW version:2.6.0 > mtnic0: Board ID: > mtnic0: Using 1 tx rings for port:1 [4096] > mtnic0: Using 4 rx rings for port:1 [1024] > mtnic0: Using 1 tx rings for port:2 [4096] > mtnic0: Using 4 rx rings for port:2 [1024] [..] > > Any idea how can such logs apear in "sysctl -a" ? > kern.msgbuf dumps so called 'message buf' containing messages printed by the kernel (for example by a NIC driver). It's accessible also via /dev/klog and syslogd uses it as a source for /var/log/messages. -- Mateusz Guzik ___ 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 not showing CPU# correctly
Hi, On Fri, Dec 26, 2008 at 8:20 PM, Nikola Knežević wrote: > on my system, I noticed that ps(1) is not showing the CPU# correctly (it > always displays 0). There was a bug in it, and it was fetching ki_estcpu > instead of ki_lastcpu. > From the man page: cpushort-term CPU usage factor (for scheduling) Apparently not last cpu's number. :) You're probably using SCHED_ULE - this scheduler does not alter td_estcpu and that's why ps -o cpu gives you only 0. -- Mateusz Guzik ___ 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: Laptop suggestions?
2008/7/30 Matt Olander <[EMAIL PROTECTED]>: > On Jul 25, 2008, at 3:23 PM, Jeremy Messenger wrote: > >> Maybe you can wait for this: >> >> http://www.ixsystems.com/products/bsd-laptop.html > > Hi everyone! I actually had our prototype of this laptop up at the OSCON > show in Portland and it was pretty well received. > Everything works for the most part although we're still tweaking some things > for ACPI. > > I'll have one at the FreeBSD booth at LinuxWorld in San Francisco next week, > August 5-7. We'll announce as soon as this thing is 100% and we're > comfortable bringing the product line up as an item that we're comfortable > supporting long term. Most likely, available to the general public in > September. > Any chances it will be available with trackpoint instead of touchpad? :) Thanks, -- Mateusz Guzik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Usage of priv_cred in sys/kern/kern_ktrace.c
Hi,
ktrace has the ability to set flag KTRFAC_ROOT, indicating that the
root user started tracing of the given process. It does the following:
if (priv_check(td, PRIV_KTRACE) == 0)
p->p_traceflag |= KTRFAC_ROOT;
I believe this check is wrong and should be changes to something like:
if (td->td_ucred->cr_uid == UID_ROOT)
p->p_traceflag |= KTRFAC_ROOT;
Also, despite the existence of PRIV_KTRACE, there's no way to disable
ktrace using the MAC framework, because priv_check is only used in case
described above.
Am I misintepreting something? If I'm right, what do You think about the
attached patch? :)
Thanks for Your time,
--
Mateusz Guzik <[EMAIL PROTECTED]>
--- sys/kern/kern_priv.c.orig 2008-03-07 16:27:08.0 +0100
+++ sys/kern/kern_priv.c 2008-07-15 22:30:56.0 +0200
@@ -86,10 +86,18 @@
error = prison_priv_check(cred, priv);
if (error)
return (error);
/*
+ * Grant some privileges typically available for normal users.
+ */
+ switch (priv) {
+ case PRIV_KTRACE:
+ return (0);
+ }
+
+ /*
* Having determined if privilege is restricted by various policies,
* now determine if privilege is granted. At this point, any policy
* may grant privilege. For now, we allow short-circuit boolean
* evaluation, so may not call all policies. Perhaps we should.
*
--- sys/kern/kern_ktrace.c.orig 2008-02-23 02:01:48.0 +0100
+++ sys/kern/kern_ktrace.c 2008-07-15 22:01:03.0 +0200
@@ -37,10 +37,11 @@
#include "opt_ktrace.h"
#include "opt_mac.h"
#include
#include
+#include
#include
#include
#include
#include
#include
@@ -610,10 +611,13 @@
int nfound, ret = 0;
int flags, error = 0, vfslocked;
struct nameidata nd;
struct ucred *cred;
+ if (priv_check(td, PRIV_KTRACE))
+ if (ops != KTROP_CLEAR && ops != KTROP_CLEARFILE)
+ return (ENOSYS);
/*
* Need something to (un)trace.
*/
if (ops != KTROP_CLEARFILE && facs == 0)
return (EINVAL);
@@ -821,11 +825,11 @@
if (p->p_tracecred != td->td_ucred) {
tracecred = p->p_tracecred;
p->p_tracecred = crhold(td->td_ucred);
}
p->p_traceflag |= facs;
- if (priv_check(td, PRIV_KTRACE) == 0)
+ if (td->td_ucred->cr_uid == UID_ROOT)
p->p_traceflag |= KTRFAC_ROOT;
} else {
/* KTROP_CLEAR */
if (((p->p_traceflag &= ~facs) & KTRFAC_MASK) == 0) {
/* no more tracing */
@@ -1027,11 +1031,11 @@
struct proc *targetp;
{
PROC_LOCK_ASSERT(targetp, MA_OWNED);
if (targetp->p_traceflag & KTRFAC_ROOT &&
- priv_check(td, PRIV_KTRACE))
+ td->td_ucred->cr_uid != UID_ROOT)
return (0);
if (p_candebug(td, targetp) != 0)
return (0);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can I change the device of the "/" mount point at boot time.
2008/7/14 Tapan Chaudhari <[EMAIL PROTECTED]>: > > Hi, > Thanks a lot Mike. But the problem is the device I am talking about is > not the physical device. I am writing a driver which will create a virtual > device and all the i/os done on this virtual device will be ultimately > redirected to the original device. Correct me if I am wrong, but I guess the > loader will try to mount my new device on '/' and then load the modules into > the kernel. Since my driver would not be loaded at that point in time, it > will fail to even mount '/'. Am I right? Or can our drivers get loaded > before loader mounts '/' ? Yes, take a look at /boot/loader.conf . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
