Re: kern_jail_set() Error Scenario Question
On 08/22/13 17:46, Matt Miller wrote:
> We ran into the following scenario in an application recently and were
> wondering if the behavior of kern_jail_set() is as expected here.
>
> This was an application bug where we were in, say, the JID 1 context
> and tried to call jailparam_set() with the flags (JAIL_CREATE |
> JAIL_UPDATE) and the "jid" param set to 1. The basic idea was to
> create or update JID 1 with some params, but the error was we were
> already in the JID 1 context. So, our understanding is this shouldn't
> work since JID 1 already exists and you can only modify it from a
> proper ancestor.
>
> However, rather than getting an error back from jailparam_set(), it
> ended up creating a second prison with JID 1, so there were two
> prisons existing with JID 1 at that point. This is based on 8.2.0
> code, but, at first glance, it looks like the logic causing this may
> be the same in head.
>
> Looking at kern_jail_set(), what happens here is:
>
> 1. We find a prison with JID=1, however since it's not a proper child
> we set pr = NULL in line 1024:
>
> 1011 pr = prison_find(jid);
> 1012 if (pr != NULL) {
> 1013 ppr = pr->pr_parent;
> 1014 /* Create: jid must not exist. */
> 1015 if (cuflags == JAIL_CREATE) {
> 1016 mtx_unlock(&pr->pr_mtx);
> 1017 error = EEXIST;
> 1018 vfs_opterror(opts, "jail %d
> already exists",
> 1019 jid);
> 1020 goto done_unlock_list;
> 1021 }
> 1022 if (!prison_ischild(mypr, pr)) {
> 1023 mtx_unlock(&pr->pr_mtx);
> 1024 pr = NULL;
> 1025 } else if (pr->pr_uref == 0) {
>
> 2. Since pr is NULL, we create a new prison. Since the jid is not
> zero, we insert it in the list and set its pr_id. At this point, we
> have two prisons with a JID of 1 and the same parent prison.
>
> 1166 /* If there's no prison to update, create a new one and
> link it in. */
> 1167 if (pr == NULL) {
> ...
> 1185 pr = malloc(sizeof(*pr), M_PRISON, M_WAITOK | M_ZERO);
> 1186 if (jid == 0) {
> ...
> 1212 } else {
> 1213 /*
> 1214 * The jail already has a jid (that did
> not yet exist),
> 1215 * so just find where to insert it.
> 1216 */
> 1217 TAILQ_FOREACH(tpr, &allprison, pr_list)
> 1218 if (tpr->pr_id >= jid) {
> 1219 TAILQ_INSERT_BEFORE(tpr,
> pr, pr_list);
> 1220 break;
> 1221 }
> 1222 }
> ...
> 1229 pr->pr_parent = ppr;
> 1230 pr->pr_id = jid;
>
> We wanted to see if this is per design or a situation that should
> avoid creating the second prison and return an error.
That's definitely not per design. I'll try reproducing this, and put in
correct logic. The proper response is indeed an error: ENOENT, because
from inside the JID 1 context you shouldn't be able to see jail #1 (you
can't operate on your own jail).
- Jamie
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Kernel Panic - Unix socket communication in kernel module
On Monday, July 29, 2013 3:31:49 am varanasi sainath wrote: > Hello, > > I am writing a kernel module in which I am trying to connect to a UNIX > socket > (UNIX domain sockets use the file system as their address name space). > Kernel module (loadable) acts as a client and User mode program acts as > server, > I have loaded the module using kldload and communication between > user and kernel module works fine, > when I try to load the kernel module from loader.conf - > auto load the kernel module at boot up leads to kernel panic > as the file system is not ready and kern_connect fails. > > How to notify kernel module that File system is ready? > (any specific event flags) > > Is there any specific location for Unix domain socket files? > (currently created it under /root/soc/socket ) > > Using "MODULE_DEPEND" Can I make the module dependent of file system? You can register a hook for the 'mountroot' EVENTHANDLER event which will fire after / is mounted. (You could compare rootvnode against NULL during module startup to determine if you should defer your work to the EVENTHANDLER vs doing it right away.) If you need to wait for all local filesystems to be mounted, then you will need to have some userland utility poke your module via a sysctl/ioctl/etc. after the filesystems are mounted (you could use a custom rc.d script for this). -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: UUID in fstab.
On Wednesday, August 21, 2013 4:38:00 pm varanasi sainath wrote: > Thanks for the support. > > I want to use the uuid's found using sysctl -a in fstab. > /dev/gptid/ has only uuid for boot partition. You probably have the other GPT paritions already mounted via another name which removes the names in /dev/gptid. Try booting an install CD or USB stick such that you use an alternate root fs and don't mount any of the partitions on your drive. Then you should be able to see the entries in /dev/gptid and update your fstab appropriately. If you console access you could also try to update your fstab to use /dev/gptid/ directly instead of /dev/XXXpYY and reboot. If it works I believe the /dev/XXXpYY names will now be gone from /dev and the /dev/gptid names present instead. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
g_vfs_done and error 11 (EDEADLK)
Anyone know why FreeBSD would give g_vfs_done errors with EDEADLK? Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65968111616, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65968373760, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65968635904, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65968865280, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65969127424, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65969389568, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65969651712, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65969881088, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65970143232, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65970405376, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65970667520, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65970896896, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65971159040, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65971421184, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65971683328, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65971912704, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[READ(offset=81416159232, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():gpt/enc.eli[WRITE(offset=65848246272, length=32768)]error = 11 Aug 22 15:31:14 drum kernel: g_vfs_done():ufs/var[WRITE(offset=1275428864, length=16384)]error = 11 The gpt/enc.eli is a GELI partition. ufs/var is not. If I go to the offset in ufs/var, it turns out to point to the syslog entry corresponding to the previous line. What's really strange is that none of the files on either disk appear to be corrupted. smartctl shows no errors on either drive. dding the entire drive produces no errors. The GELI drive is exported via samba. The errors are triggered when accessing the samba share from a PC. This is not reliably repeatable. My question is: What does error = 11 mean in this context? FreeBSD drum.msfc.nasa.gov 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254654: Thu Aug 22 09:13:25 CDT 2013 j...@drum.msfc.nasa.gov:/usr/obj/usr/src/sys/BORODIN9 i386 -- J. Porter Clark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: hugin?
On 08/23/13 07:10, Warren Block wrote: > On Thu, 22 Aug 2013, Gary Aitken wrote: > >> Is anyone using the current port of hugin successfully on 9.1? I've >> never used it before but an attempt to start it crashes: >> >> $ hugin /usr/local/share/hugin/data/plugins/top_five.py CAT:Control >> Points NAM:keep 5 CPs per image pair >> /usr/local/share/hugin/data/plugins/woa.py CAT:Control Points >> NAM:Warped Overlap Analysis >> /usr/local/share/hugin/data/plugins/shooting_pattern.py CAT:initial >> distribution NAM:6-1-1 Shooting Pattern >> /usr/local/share/hugin/data/plugins/crop_cp.py CAT:Control Points >> NAM:Crop Control Points Segmentation fault: 11 (core dumped) > > That could be from having the OpenGL preview window enabled. In > ~/.hugin, go to the [GLPreviewFrame] section and set isShown to zero. > After the program starts, that can be set in the Preferences: > File/Preferences/Assistant "After align open". Set it to "Preview > Window" rather than "Fast preview window". I don't see any "GLPreviewFrame", or any "Preview" at all; or any "Shown": cat .hugin version=2012.0 [AutoPano] AutoPanoCount=10 Default=0 [AutoPano/AutoPano_0] Type=1 Description=Hugin's CPFind Program=cpfind Arguments=--multirow -o %o %s ProgramMatcher= ArgumentsMatcher= Option=1 [AutoPano/AutoPano_1] Type=1 Description=Hugin's CPFind + Celeste (slower but more accurate, no cps on clouds) Program=cpfind Arguments=--celeste --multirow -o %o %s ProgramMatcher= ArgumentsMatcher= Option=1 [AutoPano/AutoPano_2] Type=2 Description=Cpfind (multirow/stacked) Program=cpfind Arguments=-o %o --multirow %s ProgramMatcher= ArgumentsMatcher= ProgramStack=align_image_stack ArgumentsStack=-f %v -v -p %o %i Option=1 [AutoPano/AutoPano_3] Type=1 Description=Autopano-SIFT-C Program=autopano-noop.sh Arguments=--maxmatches %p --projection %f,%v %o %i ProgramMatcher= ArgumentsMatcher= Option=1 [AutoPano/AutoPano_4] Type=1 Description=Panomatic Program=panomatic Arguments=-o %o %i ProgramMatcher= ArgumentsMatcher= Option=1 [AutoPano/AutoPano_5] Type=4 Description=Autopano-SIFT-C (multirow/stacked) Program=generatekeys Arguments=%i %k 800 ProgramMatcher=autopano ArgumentsMatcher=--maxmatches %p %o %k ArgumentsCleanup= ProgramStack=align_image_stack ArgumentsStack=-f %v -v -p %o %i Option=1 [AutoPano/AutoPano_6] Type=1 Description=Align image stack Program=align_image_stack Arguments=-f %v -v -p %o %i ProgramMatcher= ArgumentsMatcher= Option=1 [AutoPano/AutoPano_7] Type=1 Description=Align image stack FullFrameFisheye Program=align_image_stack Arguments=-f %v -e -p %o %i ProgramMatcher= ArgumentsMatcher= Option=1 [AutoPano/AutoPano_8] Type=1 Description=Vertical lines Program=linefind Arguments=-o %o %s ProgramMatcher= ArgumentsMatcher= Option=1 [AutoPano/AutoPano_9] Type=1 Description=Hugin's CPFind (prealigned) Program=cpfind Arguments=--prealigned -o %o %s ProgramMatcher= ArgumentsMatcher= Option=1 gdb shows the following: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 812807400 (LWP 100339/hugin)] 0x00080525cab0 in wxWindow::DoSetSize () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 (gdb) where #0 0x00080525cab0 in wxWindow::DoSetSize () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #1 0x000805342c7e in wxBoxSizer::RecalcSizes () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #2 0x0008053546f0 in wxWindowBase::Layout () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #3 0x00080537f5d6 in wxPanel::OnSize () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #4 0x000804dfe48d in wxEvtHandler::ProcessEventIfMatches () from /usr/local/lib/libwx_baseu-2.8.so.0 #5 0x000804dfe64c in wxEventHashTable::HandleEvent () from /usr/local/lib/libwx_baseu-2.8.so.0 #6 0x000804dfe78d in wxEvtHandler::ProcessEvent () from /usr/local/lib/libwx_baseu-2.8.so.0 #7 0x00080525ca85 in wxWindow::DoSetSize () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #8 0x000805342c7e in wxBoxSizer::RecalcSizes () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #9 0x000805342c03 in wxBoxSizer::RecalcSizes () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #10 0x000805342c7e in wxBoxSizer::RecalcSizes () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #11 0x000805342c03 in wxBoxSizer::RecalcSizes () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #12 0x000805342c7e in wxBoxSizer::RecalcSizes () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #13 0x000805342c7e in wxBoxSizer::RecalcSizes () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #14 0x0008053546f0 in wxWindowBase::Layout () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #15 0x0008056b7f08 in wxAuiManager::DoFrameLayout () from /usr/local/lib/libwx_gtk2u_aui-2.8.so.0 #16 0x0008056bf720 in wxAuiManager::Update () from /usr/local/lib/libwx_gtk2u_aui-2.8.so.0 #17 0x0054e0b8 in HuginBase::Nona::ReduceStitcher, std::allocator > >, vigra::BasicImage > >::stitch, vigra::RGBValue**>, vigra::RGBAccessor >, vigra::Bas
Re: hugin?
On Thu, 22 Aug 2013, Gary Aitken wrote: Is anyone using the current port of hugin successfully on 9.1? I've never used it before but an attempt to start it crashes: $ hugin /usr/local/share/hugin/data/plugins/top_five.py CAT:Control Points NAM:keep 5 CPs per image pair /usr/local/share/hugin/data/plugins/woa.py CAT:Control Points NAM:Warped Overlap Analysis /usr/local/share/hugin/data/plugins/shooting_pattern.py CAT:initial distribution NAM:6-1-1 Shooting Pattern /usr/local/share/hugin/data/plugins/crop_cp.py CAT:Control Points NAM:Crop Control Points Segmentation fault: 11 (core dumped) That could be from having the OpenGL preview window enabled. In ~/.hugin, go to the [GLPreviewFrame] section and set isShown to zero. After the program starts, that can be set in the Preferences: File/Preferences/Assistant "After align open". Set it to "Preview Window" rather than "Fast preview window". ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Finding exactly which commands, and in which order, rc is running at startup
On 23 August 2013 10:41, Doug Hardie wrote: > > On 22 August 2013, at 13:07, Paul Hoffman wrote: > > > Greetings again. After doing a freebsd-update, my system is starting up > differently than it was before. I want to figure out why before I come here > and say "it's broken". > > > > Is there a way to say "show me all of the commands you are running > during startup"? It would be grand if I could say "tell me what you would > do next time (dry run)", but "what did you do last time" is OK too. > > You can add: > > rc_debug="YES" > > to /etc/rc.conf and that might give you what you need. According to the > man page it will "produces copious output to the terminal and syslog(3)" > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > You can use "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" to show the order of which the startup scripts is run. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Finding exactly which commands, and in which order, rc is running at startup
On 22 August 2013, at 13:07, Paul Hoffman wrote: > Greetings again. After doing a freebsd-update, my system is starting up > differently than it was before. I want to figure out why before I come here > and say "it's broken". > > Is there a way to say "show me all of the commands you are running during > startup"? It would be grand if I could say "tell me what you would do next > time (dry run)", but "what did you do last time" is OK too. You can add: rc_debug="YES" to /etc/rc.conf and that might give you what you need. According to the man page it will "produces copious output to the terminal and syslog(3)" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
