Re: zfs kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?
On Fri, Jun 14, 2013 at 11:07:02PM +0200, Alexander Leidinger wrote: db bt Tracing pid 2356 uart_sab82532_class() at 0 devfs_ioctl_f() at devfs_ioctl_f+0xf0 kern_ioctl() at kern_ioctl+0x1d7 sys_ioctl() at sys_ioctl+0x142 ---snip--- Anyone with a pointer to an explanation how to convert those pointers into source locations? kgdb l *devfs_ioctl_f+0xf0 -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB Keyboard not worked on current (r251681)
On Sat, Jun 15, 2013 at 09:34:59AM +0200, Hans Petter Selasky wrote: It is some error code from busdma. This is not helpful, obviously. We need to know exactly what call failed, with what parameters together with the values from the tag. Then the hypothesis about the system state could be made and corresponding information requested. --HPS -Original message- From:Konstantin Belousov kostik...@gmail.com Sent: Saturday 15th June 2013 7:29 To: Sergey V. Dyatko sergey.dya...@gmail.com Cc: k...@freebsd.org; curr...@freebsd.org Subject: Re: USB Keyboard not worked on current (r251681) On Fri, Jun 14, 2013 at 12:41:28PM +0300, Sergey V. Dyatko wrote: On Fri, 14 Jun 2013 11:36:56 +0200 Hans Petter Selasky h...@bitfrost.no wrote: See this thread and solution Supermicro 6027R-N3RF+head, usb trouble It was 'fixed' by r251282, but I see r251681 on subject :) added kib@ to Cc It was not 'fixed', I reacted on something which was wrong on its own, and which was accidentally reported to somehow cover/fix the USB issue. You have to trace does the real cause of the USB failure, in particular, to find the place where USB_ERR_NOMEM comes from. But, the error from the usbd_ctrl_transfer_setup: 'could not setup default USB transfer' comes before ENOMEM and its cause is lost in the USB code. pgpS3osOr6x40.pgp Description: PGP signature
Re: copyin()/copyout() constraints ?
On Fri, Jun 14, 2013 at 02:59:57PM -0700, Alfred Perlstein wrote: On 6/14/13 9:38 AM, Luigi Rizzo wrote: On Fri, Jun 14, 2013 at 12:07:29PM -0400, John Baldwin wrote: On Wednesday, June 12, 2013 2:36:52 pm Alfred Perlstein wrote: On 6/12/13 11:01 AM, Luigi Rizzo wrote: hi, is it possible to run copyin() or copyout() in one of these cases: 1. while holding a spinlock 2. while holding a regular mutex/lock 3. while holding a read lock (on an RWLOCK or RMLOCK) 4. while holding a write lock (on an RWLOCK or RMLOCK) I suspect #1 is forbidden, but am a bit unclear for the other cases. No on all of the above unless the memory is wired. ok i suppose i'll move to an sx lock, which i have been told allows me to sleep ? My use case is that while i run the copyin(), and possibly take a page fault, nobody destroys the destination buffer. So i wanted to hold a read lock (sx_slock() ?) in the thread doing the copy (there may be several writers to different parts of the destination), and a write lock (sx_xlock() ?) for the other thread which may destroy the buffer. We may be putting cart before horse, or horse into cart or something. :) You may want to just wire the user buffer so it can't get ripped out from under you. I'll investigate, but i am not sure i can afford the cost of wiring and unwiring every single buffer. My application is a VALE/netmap switch interconnecting two virtual machines, as below: B and C are netmap buffers, and are wired (in the host) A is an mbuf/skbuf within the guest OS (so for the host is not wired). The current code is able to push 5-6 Mpps with 3 copies: A-B (done in userspace by a qemu thread for VM1), B-C (a memcpy in the kernel of the host) C-D (done in userspace by a qemu thread for VM2) With indirect buffers in netmap/vale, i can eliminate the A-B copy, and do A-C with a copyin in the kernel of the host. But the per-packet budget is minuscule, and i am afraid that doing an unconditional vslock() on each buffer is going to be too expensive (and then i should also unwire the page ? ++ +---+ +--+ | VM1| | VALE switch | | VM2 | || | | | | | mbuf | | .-+ .-. | | mbuf | | .--. | | |B|memcpy |C| | | .-. | | |A +-- +--| +-|D| | | | | | | | | (now) | | | | | | | | | | | | '-' '-+---' | | | | | | | | | | copyin ^ | | | | | | | +--' | | | | | | '--' | | (with indirect buffers) | | '-' | || | | | | ++ +---+ +--+ cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: copyin()/copyout() constraints ?
On Sat, Jun 15, 2013 at 01:26:10PM +0200, Luigi Rizzo wrote: With indirect buffers in netmap/vale, i can eliminate the A-B copy, and do A-C with a copyin in the kernel of the host. But the per-packet budget is minuscule, and i am afraid that doing an unconditional vslock() on each buffer is going to be too expensive (and then i should also unwire the page ? Using vslock() causes enormous user map fragmentation and should be avoided. The cost is basically the same as the page fault, since vslock() is a wrapper around vm_map_wire(), which just calls page fault handler for each address in region. On the other hand, I do not understand how any kernel-side lock would prevent usermode from unmapping a buffer while other thread in kernel mode access it. IMO you would be much better served with either with proc_rwmem(), as discussed before, or direct use of vm_fault_quick_hold_pages() and uiomove_fromphys() afterward. vm_fault_quick_hold_pages() also makes you code immune against usermode doing any unmap or mapping over the passed buffer. pgphaJZJIuvh5.pgp Description: PGP signature
Re: copyin()/copyout() constraints ?
On Sat, Jun 15, 2013 at 02:31:34PM +0300, Konstantin Belousov wrote: On Sat, Jun 15, 2013 at 01:26:10PM +0200, Luigi Rizzo wrote: With indirect buffers in netmap/vale, i can eliminate the A-B copy, and do A-C with a copyin in the kernel of the host. But the per-packet budget is minuscule, and i am afraid that doing an unconditional vslock() on each buffer is going to be too expensive (and then i should also unwire the page ? Using vslock() causes enormous user map fragmentation and should be avoided. The cost is basically the same as the page fault, since vslock() is a wrapper around vm_map_wire(), which just calls page fault handler for each address in region. On the other hand, I do not understand how any kernel-side lock would prevent usermode from unmapping a buffer while other thread in kernel mode access it. the lock i was talking about in previous emails protects the in-kernel data structures (B, C and the VALE switch), which are manipulated within system calls. The user buffer A is not protected, i am happy to take a page fault in the rare case it happens (and normally it won't because in my application A has been written to just moments before). cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: USB Keyboard not worked on current (r251681)
It is some error code from busdma. --HPS -Original message- From:Konstantin Belousov kostik...@gmail.com Sent: Saturday 15th June 2013 7:29 To: Sergey V. Dyatko sergey.dya...@gmail.com Cc: k...@freebsd.org; curr...@freebsd.org Subject: Re: USB Keyboard not worked on current (r251681) On Fri, Jun 14, 2013 at 12:41:28PM +0300, Sergey V. Dyatko wrote: On Fri, 14 Jun 2013 11:36:56 +0200 Hans Petter Selasky h...@bitfrost.no wrote: See this thread and solution Supermicro 6027R-N3RF+head, usb trouble It was 'fixed' by r251282, but I see r251681 on subject :) added kib@ to Cc It was not 'fixed', I reacted on something which was wrong on its own, and which was accidentally reported to somehow cover/fix the USB issue. You have to trace does the real cause of the USB failure, in particular, to find the place where USB_ERR_NOMEM comes from. But, the error from the usbd_ctrl_transfer_setup: 'could not setup default USB transfer' comes before ENOMEM and its cause is lost in the USB code. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: USB Keyboard not worked on current (r251681)
Hi, sys/dev/usb/usb_busdma.c Just add error printf() there in all cases. Should be trivial. Probably also something is printed by: sysctl hw.usb.debug=15 --HPS -Original message- From:Konstantin Belousov kostik...@gmail.com Sent: Saturday 15th June 2013 12:24 To: Hans Petter Selasky hans.petter.sela...@bitfrost.no Cc: Sergey V. Dyatko sergey.dya...@gmail.com; curr...@freebsd.org Subject: Re: USB Keyboard not worked on current (r251681) On Sat, Jun 15, 2013 at 09:34:59AM +0200, Hans Petter Selasky wrote: It is some error code from busdma. This is not helpful, obviously. We need to know exactly what call failed, with what parameters together with the values from the tag. Then the hypothesis about the system state could be made and corresponding information requested. --HPS -Original message- From:Konstantin Belousov kostik...@gmail.com Sent: Saturday 15th June 2013 7:29 To: Sergey V. Dyatko sergey.dya...@gmail.com Cc: k...@freebsd.org; curr...@freebsd.org Subject: Re: USB Keyboard not worked on current (r251681) On Fri, Jun 14, 2013 at 12:41:28PM +0300, Sergey V. Dyatko wrote: On Fri, 14 Jun 2013 11:36:56 +0200 Hans Petter Selasky h...@bitfrost.no wrote: See this thread and solution Supermicro 6027R-N3RF+head, usb trouble It was 'fixed' by r251282, but I see r251681 on subject :) added kib@ to Cc It was not 'fixed', I reacted on something which was wrong on its own, and which was accidentally reported to somehow cover/fix the USB issue. You have to trace does the real cause of the USB failure, in particular, to find the place where USB_ERR_NOMEM comes from. But, the error from the usbd_ctrl_transfer_setup: 'could not setup default USB transfer' comes before ENOMEM and its cause is lost in the USB code. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2013-06-15 17:30:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-06-15 17:30:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-06-15 17:30:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-06-15 17:30:17 - cleaning the object tree TB --- 2013-06-15 17:33:23 - /usr/local/bin/svn stat /src TB --- 2013-06-15 17:33:26 - At svn revision 251793 TB --- 2013-06-15 17:33:27 - building world TB --- 2013-06-15 17:33:27 - CROSS_BUILD_TESTING=YES TB --- 2013-06-15 17:33:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-15 17:33:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-15 17:33:27 - SRCCONF=/dev/null TB --- 2013-06-15 17:33:27 - TARGET=i386 TB --- 2013-06-15 17:33:27 - TARGET_ARCH=i386 TB --- 2013-06-15 17:33:27 - TZ=UTC TB --- 2013-06-15 17:33:27 - __MAKE_CONF=/dev/null TB --- 2013-06-15 17:33:27 - cd /src TB --- 2013-06-15 17:33:27 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Jun 15 17:33:34 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils -I. -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\/obj/i386.i386/src/tmp\ -I/obj/i386.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp -o PromoteMemoryToRegister.o c++ -O2 -pipe -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils -I. -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\/obj/i386.i386/src/tmp\ -I/obj/i386.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SSAUpdater.cpp -o SSAUpdater.o c++ -O2 -pipe -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils -I. -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\/obj/i386.i386/src/tmp\ -I/obj/i386.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SimplifyCFG.cpp -o SimplifyCFG.o /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SimplifyCFG.cpp: In function 'bool llvm::FoldBranchToCommonDest(llvm::BranchInst*)': /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1988: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop. make: stopped in /src/lib/clang/libllvmtransformutils *** Error code 1 Stop. make: stopped in /src/lib/clang === lib/clang/include (install) sh /src/tools/install.sh -C -o root -g wheel -m 444 /src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__wmmintrin_aes.h /src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__wmmintrin_pclmul.h /src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/altivec.h /src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/ammintrin.h /src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx2intrin.h /src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avxintrin.h
Re: [drm2][panic] Running XOrg with SNA enabled causes system panic after few hours on G33
Can you please also create patch for -current?
On Saturday 15 June 2013 08:17:46 Konstantin Belousov wrote:
On Fri, Jun 14, 2013 at 10:16:15AM +0300, Artyom Mirgorodskiy wrote:
Thank you! This patch also solve my issue (unable shutdown):
http://lists.freebsd.org/pipermail/freebsd-current/2013-May/042011.html
On Tuesday 11 June 2013 12:34:16 Oleg Sidorkin wrote:
Hello.
I'm running recent 9.1/stable with the recent XOrg on the system with
G33 chipset.
My pciconf -lvb output is here: http://pastebin.com/LDzKzf1i
If I add
Option AccelMethod sna
to my xorg.conf system panics after few hours:
(kgdb) bt
#0 doadump (textdump=value optimized out)
at /usr/src/sys/kern/kern_
shutdown.c:272
#1 0x8050a19f in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0x8050a6a3 in panic (fmt=0x104 Address 0x104 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0x80765f77 in vm_page_insert (m=0xfe0226126b50,
object=0xfe0208de8488, pindex=3) at /usr/src/sys/vm/vm_page.c:914
#4 0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
offset=3, prot=value optimized out, mres=0xff824705b680)
at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1429
#5 0x80747fe3 in dev_pager_getpages (object=0xfe0208de8488,
ma=0xff824705b680, count=1, reqpage=value optimized out)
at /usr/src/sys/vm/device_pager.c:260
#6 0x80754bb6 in vm_fault_hold (map=0xfe000c247188,
vaddr=34458505216, fault_type=2 '\002', fault_flags=0, m_hold=0x0)
at vm_pager.h:128
#7 0x80756ca3 in vm_fault (map=0xfe000c247188,
vaddr=34458505216,
fault_type=value optimized out, fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:229
#8 0x8078e01f in trap_pfault (frame=0xff824705bc40,
usermode=1)
at /usr/src/sys/amd64/amd64/trap.c:762
#9 0x8078e864 in trap (frame=0xff824705bc40)
(kgdb) bt full
#0 doadump (textdump=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:272
No locals.
#1 0x8050a19f in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
_ep = (struct eventhandler_entry *) 0x0
_el = (struct eventhandler_list *) 0xfe0009c7f700
first_buf_printf = 1
#2 0x8050a6a3 in panic (fmt=0x104 Address 0x104 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
td = (struct thread *) 0x0
bootopt = value optimized out
newpanic = value optimized out
ap = {{gp_offset = 8, fp_offset = 48,
overflow_arg_area = 0xff824705b570,
reg_save_area = 0xff824705b490}}
panic_cpu = 3
buf = vm_page_insert: page already inserted, '\0' repeats 218
times
#3 0x80765f77 in vm_page_insert (m=0xfe0226126b50,
object=0xfe0208de8488, pindex=3) at /usr/src/sys/vm/vm_page.c:914
root = 0x0
#4 0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
offset=3, prot=value optimized out, mres=0xff824705b680)
(kgdb) up 4
#4 0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
offset=3, prot=value optimized out, mres=0xff824705b680)
at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1429
1429vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
(kgdb) p vm_obj
$1 = 0xfe0208de8488
(kgdb) p m-object
$2 = 0xfe0208de8488
It works fine for weeks without Option AccelMethod sna.
I replaced
vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
with the code
if (m-object==NULL){
vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
}
else{
if(m-object!=vm_obj)
panic(i915_gem_pager_fault: tried to assign already
assigned page to the different object);
}
and it worked with SNA enabled for about a week with no problems. But
I'm not sure that is a good solution.
I can provide additional info if required.
Thanks
--
Oleg Sidorkin
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org
I did not see the original mail with the backtrace.
FWIW, it seems that the issue is that other thread might have faulted
on the same GTT offset and bound the page before the paniced thread.
If this is indeed the situation, then the proper fix is to check for
the race, and not to just avoid the insertion. Re-instantiating the
fences is particularly wrong IMO.
Try this patch (untested, I only compiled it).
diff --git a/sys/dev/drm2/i915/i915_gem.c
Re: [drm2][panic] Running XOrg with SNA enabled causes system panic after few hours on G33
On Sat, Jun 15, 2013 at 09:46:02PM +0300, Artyom Mirgorodskiy wrote: Can you please also create patch for -current? It is for current. Code in stable/9 should be identical though. pgp78Kyej0eyX.pgp Description: PGP signature
Re: [drm2][panic] Running XOrg with SNA enabled causes system panic after few hours on G33
I can't apply patch On Saturday 15 June 2013 21:48:08 Konstantin Belousov wrote: On Sat, Jun 15, 2013 at 09:46:02PM +0300, Artyom Mirgorodskiy wrote: Can you please also create patch for -current? It is for current. Code in stable/9 should be identical though. -- Artyom Mirgorodskiy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: zfs kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?
On Sat, 15 Jun 2013 11:17:07 +0300 Mikolaj Golub troc...@freebsd.org wrote: On Fri, Jun 14, 2013 at 11:07:02PM +0200, Alexander Leidinger wrote: db bt Tracing pid 2356 uart_sab82532_class() at 0 devfs_ioctl_f() at devfs_ioctl_f+0xf0 kern_ioctl() at kern_ioctl+0x1d7 sys_ioctl() at sys_ioctl+0x142 ---snip--- Anyone with a pointer to an explanation how to convert those pointers into source locations? kgdb l *devfs_ioctl_f+0xf0 I have the old kernel loaded and have the new one in kgdb. It seems it is loading the symbols of the modules for the old kernel. As devfs is not a module, it shouldn't matter here. ---snip--- (kgdb) l *devfs_ioctl_f+0xf0 0x80346dd0 is in devfs_ioctl_f (/space/system/usr_src/sys/fs/devfs/devfs_vnops.c:757). 752 error = copyout(p, fgn-buf, i); 753 td-td_fpop = fpop; 754 dev_relthread(dev, ref); 755 return (error); 756 } 757 error = dsw-d_ioctl(dev, com, data, fp-f_flag, td); 758 td-td_fpop = NULL; 759 dev_relthread(dev, ref); 760 if (error == ENOIOCTL) 761 error = ENOTTY; ---snip--- I would assume I can not print anything from there with my core-dump, as the backtrace is not usable. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: A PRIV_* flag for /dev/mem?
On 05/20/13 16:56, Kirk McKusick wrote:
I pointed Robert and Pawel at your discussion on creating a new
PRIV_KMEM and adding a check for it in memopen(). I am of the opinion
that this is a good idea, but I am hoping that one of Robert or Pawel
will comment since they are much more active in this area.
I suppose it's safe to say further comment isn't forthcoming. So with
one vote for and one against (or at least questioning), I'll humbly
leave it up to myself to be the tie-breaker :-).
Here's a proposed patch. I separate kmem access into read and write, as
I saw other similar splits in the priv list. Perhaps that's overkill,
and I can use a single PRIV_KMEM instead of PRIV_KMEM_READ and
PRIV_KMEM_WRITE.
Perhaps this is an overreach, because PRIV_KMEM_READ is used where the
default isn't root privilege: the file permission and expected usage are
group kmem gets to read /dev/[k]mem. I'm not about to go hard-coding a
gid into the kernel, so it seems the proper thing to do (not included in
the patch) would be to allow PRIV_KMEM_READ by default. I thought there
might already be such cases where the default is to allow, but no: this
would be the first default-allow permission. So perhaps the best answer
is not worry about that one, and only add PRIV_KMEM_WRITE (leaving reads
controlled by file permission alone as they are now).
- Jamie
Index: sys/sys/priv.h
===
--- sys/sys/priv.h (revision 251793)
+++ sys/sys/priv.h (working copy)
@@ -494,9 +494,15 @@
#definePRIV_RCTL_REMOVE_RULE 674
/*
+ * Kernel memory privileges.
+ */
+#definePRIV_KMEM_READ 680 /* Read from kernel memory. */
+#definePRIV_KMEM_WRITE 681 /* Write to kernel memory. */
+
+/*
* Track end of privilege list.
*/
-#define_PRIV_HIGHEST 675
+#define_PRIV_HIGHEST 682
/*
* Validate that a named privilege is known by the privilege system. Invalid
Index: sys/kern/kern_priv.c
===
--- sys/kern/kern_priv.c(revision 251793)
+++ sys/kern/kern_priv.c(working copy)
@@ -142,6 +142,15 @@
}
/*
+* Writes to kernel memory are a typical root-only operation,
+* but non-root users are expected to be able to read it.
+*/
+ if (priv == PRIV_KMEM_READ) {
+ error = 0;
+ goto out;
+ }
+
+ /*
* Now check with MAC, if enabled, to see if a policy module grants
* privilege.
*/
Index: sys/dev/mem/memdev.c
===
--- sys/dev/mem/memdev.c(revision 251793)
+++ sys/dev/mem/memdev.c(working copy)
@@ -67,8 +67,14 @@
{
int error = 0;
- if (flags FWRITE)
- error = securelevel_gt(td-td_ucred, 0);
+ if (flags FREAD)
+ error = priv_check(td, PRIV_KMEM_READ);
+ if (flags FWRITE) {
+ if (error != 0)
+ error = priv_check(td, PRIV_KMEM_WRITE);
+ if (error != 0)
+ error = securelevel_gt(td-td_ucred, 0);
+ }
return (error);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
