From alexbestms at math.uni-muenster.de Wed Jul 1 00:01:57 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Jul 1 00:02:04 2009 Subject: c question: *printf'ing arrays In-Reply-To: <20090630225457.GR84786@elvis.mu.org> Message-ID: wow. thanks. that's looking really nice. i'll change my sources tomorrow after a good dose of sleep. ;) alex Alfred Perlstein schrieb am 2009-07-01: > Hey Alex, > People frown on macros, but this could be a good one: > #define SPRINT(f, fmt) \ > do {\ > for (_i = 0; _i < sizeof(f)/sizeof(f[0]); i++) \ > printf(fmt, f[i]); \ > }while(0) > :D > This should allow you to point to any _array_ and print each > element of it using format "fmt". > Example: > SPRINT(Header->game_title, "%c"); > -Alfred > * Alexander Best [090630 15:06] > wrote: > > thanks for all the help. i decided to take the pill and coded all > > the fprintfs > > by hand. here's the result. usually i'd stick to a higher level > > languag, but i > > need C's inline assembly support: > > struct Header > > { > > u_int8_t rom_entry[4]; > > u_int8_t nintendo_logo[156]; > > u_char game_title[12]; > > u_char game_code[4]; > > u_char maker_code[2]; > > u_int8_t fixed_val; > > u_int8_t unit_code; > > u_int8_t device_type; > > u_int8_t reserved_area1[7]; > > u_int8_t software_version; > > u_int8_t complement_check; > > u_int8_t reserved_area2; > > u_int8_t ram_entry[4]; > > u_int8_t boot_mode; > > u_int8_t slave_id; > > u_int8_t unused_area[26]; > > u_int8_t joybus_entry[4]; > > }; > > struct Header * hdr = rom; > > int i; > > fprintf(stderr, "ROM Entry: 0x"); > > for (i=0; i < 4; i++) fprintf(stderr, "%x", hdr->rom_entry[i]); > > fprintf(stderr, "\nNintendo Logo: 0x"); > > for (i=0; i < sizeof(hdr->nintendo_logo); i++) fprintf(stderr, > > "%x", > > hdr->nintendo_logo[i]); > > fprintf(stderr, "\nGame Title: %s", hdr->game_title); > > fprintf(stderr, "\nGame Code: %s", hdr->game_code); > > fprintf(stderr, "\nMaker Code: %s", hdr->maker_code); > > fprintf(stderr, "\nFixed Value: 0x"); > > fprintf(stderr, "%x", hdr->fixed_val); > > fprintf(stderr, "\nUnit Code: 0x"); > > fprintf(stderr, "%x", hdr->unit_code); > > fprintf(stderr, "\nDevice Type: 0x"); > > fprintf(stderr, "%x", hdr->device_type); > > fprintf(stderr, "\nReserved Area: 0x"); > > for (i=0; i < sizeof(hdr->reserved_area1); i++) fprintf(stderr, > > "%x", > > hdr->reserved_area1[i]); > > fprintf(stderr, "\nSoftware Version: 0x"); > > fprintf(stderr, "%x", hdr->software_version); > > fprintf(stderr, "\nComplement Check: 0x"); > > fprintf(stderr, "%x", hdr->complement_check); > > fprintf(stderr, "\nReserved Area: 0x"); > > fprintf(stderr, "%x", hdr->reserved_area2); > > fprintf(stderr, "\nRAM Entry Point: 0x"); > > for (i=0; i < sizeof(hdr->ram_entry); i++) fprintf(stderr, > > "%x", > > hdr->ram_entry[i]); > > fprintf(stderr, "\nBoot Mode: 0x"); > > fprintf(stderr, "%x", hdr->boot_mode); > > fprintf(stderr, "\nSlave ID: 0x"); > > fprintf(stderr, "%x", hdr->slave_id); > > fprintf(stderr, "\nUnused Area: 0x"); > > for (i=0; i < sizeof(hdr->unused_area); i++) fprintf(stderr, > > "%x", > > hdr->unused_area[i]); > > fprintf(stderr, "\nJoybus Entry Point: 0x"); > > for (i=0; i < sizeof(hdr->joybus_entry); i++) fprintf(stderr, > > "%x", > > hdr->joybus_entry[i]); > > cheers. > > Rick C. Petty schrieb am 2009-06-30: > > > On Tue, Jun 30, 2009 at 08:21:03PM +0200, Alexander Best wrote: > > > > thanks. now the output gets redirected using >. i'm quite new > > > > to > > > > programming > > > > under unix. sorry for the inconvenience. > > > No problem; we all had to learn sometime. But what I suggested > > > should > > > work for every platform that adheres to POSIX. If you were using > > > fprintf/fwrite, then it would work on anything that's standard C. > > > As > > > for > > > redirection, windows command line allows the same type of > > > redirection. > > > > so i guess there is no really easy way to output an > > > > inhomogeneous > > > > struct to > > > > stdout without using a loop to output each array contained in > > > > the > > > > struct. > > > That's not something C would ever provide easily. You may want > > > to > > > use a > > > different high-level language. However, I often use macros for > > > printing > > > pieces of structures, for example I used this to print out sizes > > > of > > > kernel > > > structures: > > > #define SIZE(astruct, member) \ > > > printf("%d\t\t.%s\n", sizeof(astruct.member), #member) > > > #include > > > ... > > > struct ktr_header header; > > > struct ktr_genio genio; > > > printf("%d\tktr_header:\n", sizeof(header)); > > > SIZE(header, ktr_len); > > > SIZE(header, ktr_type); > > > SIZE(header, ktr_pid); > > > SIZE(header, ktr_comm); > > > SIZE(header, ktr_time); > > > SIZE(header, ktr_time.tv_sec); > > > SIZE(header, ktr_time.tv_sec); > > > SIZE(header, ktr_tid); > > > printf("\n%d\tktr_genio:\n", sizeof(genio)); > > > SIZE(genio, ktr_fd); > > > SIZE(genio, ktr_rw); > > > In your case, you could make a macro for each type. Without an > > > example of > > > how you want the output to look, it's hard for us to show you > > > code > > > that > > > will produce such output. > > > -- Rick C. Petty > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" From sos at deepcore.dk Wed Jul 1 12:58:25 2009 From: sos at deepcore.dk (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Wed Jul 1 14:05:50 2009 Subject: ATA driver update for 7.2RELEASE available In-Reply-To: <20090627132941.5d212017@tau.draftnet> References: <8EB69F68-8ED2-469C-B83E-2555A72630B4@deepcore.dk> <20090627132941.5d212017@tau.draftnet> Message-ID: <4202EA69-6973-4638-8A0B-040F4FAA0B27@deepcore.dk> On 27Jun, 2009, at 14:29 , Bruce Cran wrote: > On Fri, 26 Jun 2009 22:11:08 +0200 > S?ren Schmidt wrote: > >> This is a total replacement of the ATA driver, modulerized as in - >> current, but based on my WIP not from what might have happend to - >> current since I gave up maintainership. > > It's great to see the driver be modularised since removing unneeded > drivers (for example, on powerpc and embedded platforms) can save > ~200KB. Yep, thats the main idea behind this move, minimizing the footprint. With this and some of the _NO_ options to the world build an almost reasonable sized FreeBSD can be made. FreeBSD seems to have grown *alot* of fat over the last years, not to mention ports where installing one small application gets you both a pony and a barn to keep it in as a "bonus" 8^) > Could you add some documentation for the modules in /sys/conf/NOTES > please? I looked through the sources and put together the patch for > 8.0 which is avaiable at > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133162 but it sounds > like some more drivers will need to be added for 7.2. Good catch, included in my WIP here, when/if I get to put up another release of this it will be in there, thanks! PS: For official inclusion in FreeBSD someone with a commit bit will have to look into this. -S?ren -- From frederic.praca at freebsd-fr.org Wed Jul 1 21:20:23 2009 From: frederic.praca at freebsd-fr.org (=?UTF-8?B?RnLDqWTDqXJpYw==?= Praca) Date: Wed Jul 1 21:20:31 2009 Subject: Problem compiling kernel with ath device Message-ID: <20090701230101.5d50741c@tatooine> Hello guys, I got the following compilation error in if_ath.c when compiling the RELENG_7 today : ../../../dev/ath/if_ath.c: In function 'ath_rx_tap': ../../../dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' ../../../dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' *** Error code 1 After investigating, this part appears only when HAL_ABI_VERSION is greater than 0x07050400 The current value seems to be 0x08112800 as specified in ath_hal/hal.h. The problem is that for rs_flags to be present in the ath_rx_status structure, defined in ath_hal/ah_desc.h, AH_SUPPORT_AR5416 has to be defined. Do I need something more than the three following lines in my kernel configuration especially the AH_SUPPORT_AR5416 option even if my PCI card is a 5212 chipset powered ? device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath Well, in fact, I already know the answer as I compiled my kernel by adding AH_SUPPORT_AR5416 option but isn't it a problem there ? Regards Fred From unixmania at gmail.com Thu Jul 2 00:39:46 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu Jul 2 00:39:53 2009 Subject: c question: *printf'ing arrays In-Reply-To: <20090630225457.GR84786@elvis.mu.org> References: <20090630210238.GA33849@keira.kiwi-computer.com> <20090630225457.GR84786@elvis.mu.org> Message-ID: On Tue, Jun 30, 2009 at 7:54 PM, Alfred Perlstein wrote: > Hey Alex, > > People frown on macros, but this could be a good one: > > #define SPRINT(f, fmt) \ > ? ? ? ?do {\ > ? ? ? ? ? ? ? ?for (_i = 0; _i < sizeof(f)/sizeof(f[0]); i++) \ > ? ? ? ? ? ? ? ? ? ? ? ?printf(fmt, f[i]); \ > ? ? ? ?}while(0) > > :D > > This should allow you to point to any _array_ and print each > element of it using format "fmt". > > Example: > SPRINT(Header->game_title, "%c"); Yes, it works, but using a loop to print a character array one char at a time is terribly inefficient. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From unixmania at gmail.com Thu Jul 2 01:48:25 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu Jul 2 01:48:31 2009 Subject: c question: *printf'ing arrays In-Reply-To: References: <20090630210238.GA33849@keira.kiwi-computer.com> Message-ID: On Tue, Jun 30, 2009 at 7:06 PM, Alexander Best wrote: > thanks for all the help. i decided to take the pill and coded all the fprintfs > by hand. here's the result. usually i'd stick to a higher level languag, but i > need C's inline assembly support: > > ? ?struct Header > ? ?{ > ? ? ? ?u_int8_t rom_entry[4]; > ? ? ? ?u_int8_t nintendo_logo[156]; > ? ? ? ?u_char game_title[12]; > ? ? ? ?u_char game_code[4]; > ? ? ? ?u_char maker_code[2]; > ? ? ? ?u_int8_t fixed_val; > ? ? ? ?u_int8_t unit_code; > ? ? ? ?u_int8_t device_type; > ? ? ? ?u_int8_t reserved_area1[7]; > ? ? ? ?u_int8_t software_version; > ? ? ? ?u_int8_t complement_check; > ? ? ? ?u_int8_t reserved_area2; > ? ? ? ?u_int8_t ram_entry[4]; > ? ? ? ?u_int8_t boot_mode; > ? ? ? ?u_int8_t slave_id; > ? ? ? ?u_int8_t unused_area[26]; > ? ? ? ?u_int8_t joybus_entry[4]; > ? ?}; > > ? ?struct Header * hdr = rom; > ? ?int i; > > ? ?fprintf(stderr, "ROM Entry: 0x"); > ? ?for (i=0; i < 4; i++) fprintf(stderr, "%x", hdr->rom_entry[i]); > ? ?fprintf(stderr, "\nNintendo Logo: 0x"); > ? ?for (i=0; i < sizeof(hdr->nintendo_logo); i++) fprintf(stderr, "%x", > ? ?hdr->nintendo_logo[i]); > ? ?fprintf(stderr, "\nGame Title: %s", ?hdr->game_title); > ? ?fprintf(stderr, "\nGame Code: %s", ?hdr->game_code); > ? ?fprintf(stderr, "\nMaker Code: %s", ?hdr->maker_code); > ? ?fprintf(stderr, "\nFixed Value: 0x"); > ? ?fprintf(stderr, "%x", hdr->fixed_val); > ? ?fprintf(stderr, "\nUnit Code: 0x"); > ? ?fprintf(stderr, "%x", hdr->unit_code); > ? ?fprintf(stderr, "\nDevice Type: 0x"); > ? ?fprintf(stderr, "%x", hdr->device_type); > ? ?fprintf(stderr, "\nReserved Area: 0x"); > ? ?for (i=0; i < sizeof(hdr->reserved_area1); i++) fprintf(stderr, "%x", > ? ?hdr->reserved_area1[i]); > ? ?fprintf(stderr, "\nSoftware Version: 0x"); > ? ?fprintf(stderr, "%x", hdr->software_version); > ? ?fprintf(stderr, "\nComplement Check: 0x"); > ? ?fprintf(stderr, "%x", hdr->complement_check); > ? ?fprintf(stderr, "\nReserved Area: 0x"); > ? ?fprintf(stderr, "%x", hdr->reserved_area2); > ? ?fprintf(stderr, "\nRAM Entry Point: 0x"); > ? ?for (i=0; i < sizeof(hdr->ram_entry); i++) fprintf(stderr, "%x", > ? ?hdr->ram_entry[i]); > ? ?fprintf(stderr, "\nBoot Mode: 0x"); > ? ?fprintf(stderr, "%x", hdr->boot_mode); > ? ?fprintf(stderr, "\nSlave ID: 0x"); > ? ?fprintf(stderr, "%x", hdr->slave_id); > ? ?fprintf(stderr, "\nUnused Area: 0x"); > ? ?for (i=0; i < sizeof(hdr->unused_area); i++) fprintf(stderr, "%x", > ? ?hdr->unused_area[i]); > ? ?fprintf(stderr, "\nJoybus Entry Point: 0x"); > ? ?for (i=0; i < sizeof(hdr->joybus_entry); i++) fprintf(stderr, "%x", > ? ?hdr->joybus_entry[i]); The code below is a bit more efficient and easier to read. It is also safer, since it limits the width of the %s conversions to the sizes of the corresponding arrays. fprintf(stderr, "ROM Entry: 0x"); for (i=0; i < 4; i++) fprintf(stderr, "%x", hdr->rom_entry[i]); fprintf(stderr, "\nNintendo Logo: 0x"); for (i=0; i < sizeof(hdr->nintendo_logo); i++) fprintf(stderr, "%x", hdr->nintendo_logo[i]); fprintf(stderr, "\nGame Title: %.*s" "\nGame Code: %.*s" "\nMaker Code: %.*s" "\nFixed Value: 0x%x" "\nUnit Code: 0x%x" "\nDevice Type: 0x%x" "\nReserved Area: 0x", sizeof(hdr->game_title), hdr->game_title, sizeof(hdr->game_code), hdr->game_code, sizeof(hdr->maker_code), hdr->maker_code, hdr->fixed_val, hdr->unit_code, hdr->device_type); for (i=0; i < sizeof(hdr->reserved_area1); i++) fprintf(stderr, "%x", hdr->reserved_area1[i]); fprintf(stderr, "\nSoftware Version: 0x%x" "\nComplement Check: 0x%x" "\nReserved Area: 0x%x" "\nRAM Entry Point: 0x", hdr->software_version, hdr->complement_check, hdr->reserved_area2); for (i=0; i < sizeof(hdr->ram_entry); i++) fprintf(stderr, "%x", hdr->ram_entry[i]); fprintf(stderr, "\nBoot Mode: 0x""%x" "\nSlave ID: 0x""%x" "\nUnused Area: 0x", hdr->boot_mode, hdr->slave_id); for (i=0; i < sizeof(hdr->unused_area); i++) fprintf(stderr, "%x", hdr->unused_area[i]); fprintf(stderr, "\nJoybus Entry Point: 0x"); for (i=0; i < sizeof(hdr->joybus_entry); i++) fprintf(stderr, "%x", hdr->joybus_entry[i]); fprintf(stderr, "\n"); -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From des at des.no Thu Jul 2 16:03:32 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Jul 2 16:03:40 2009 Subject: c question: *printf'ing arrays In-Reply-To: (Alexander Best's message of "Wed, 01 Jul 2009 00:06:05 +0200 (CEST)") References: Message-ID: <864otvax7x.fsf@ds4.des.no> Alexander Best writes: > for (i=0; i < sizeof(hdr->nintendo_logo); i++) > fprintf(stderr, "%x", hdr->nintendo_logo[i]); What will this print if nintendo_logo is { 0x01, 0x02, 0x03, 0x04 }? DES -- Dag-Erling Sm?rgrav - des@des.no From unixmania at gmail.com Thu Jul 2 18:11:00 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu Jul 2 18:11:06 2009 Subject: c question: *printf'ing arrays In-Reply-To: <864otvax7x.fsf@ds4.des.no> References: <864otvax7x.fsf@ds4.des.no> Message-ID: 2009/7/2 Dag-Erling Sm?rgrav : > Alexander Best writes: >> ? ? for (i=0; i < sizeof(hdr->nintendo_logo); i++) >> ? ? ? ? fprintf(stderr, "%x", hdr->nintendo_logo[i]); > > What will this print if nintendo_logo is { 0x01, 0x02, 0x03, 0x04 }? Good catch. It will print "0x1234" but it should print "0x01020304". My example has the same error. The conversion specification should be "%02x", not just "%x". -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From rwatson at FreeBSD.org Thu Jul 2 18:18:50 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jul 2 18:18:57 2009 Subject: large pages (amd64) In-Reply-To: <200906301431.38664.mel.flynn+fbsd.hackers@mailing.thruhere.net> References: <200906291317.12040.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4A49CBA0.1050806@cs.rice.edu> <200906301431.38664.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: On Tue, 30 Jun 2009, Mel Flynn wrote: >>> It looks like sys/kern/kern_proc.c could call mincore around the loop at >>> line 1601 (rev 194498), but I know nothing about the vm subsystem to know >>> the implications or locking involved. There's still 16 bytes of spare to >>> consume, in the kve_vminfo struct though ;) >> >> Yes, to start with, you could replace the call to pmap_extract() with a >> call to pmap_mincore() and export a Boolean to user space that says, "This >> region of the address space contains one or more superpage mappings." > > How about attached? I like the idea -- there are some style nits that need fixing though. Assuming Alan is happy with the VM side of things, I can do the cleanup and get it in the tree. Robert N M Watson Computer Laboratory University of Cambridge > > % sudo procstat -av|grep 'S ' > PID START END PRT RES PRES REF SHD FL TP PATH > 1754 0x28900000 0x2ae00000 rw- 9385 0 3 0 --S df > 2141 0x2f900000 0x30800000 rw- 3719 0 1 0 --S df > 2146 0x3eec0000 0x4fac0000 rwx 1745 0 1 0 --S df > > -- > Mel > > From ez.c0re at gmail.com Fri Jul 3 13:46:59 2009 From: ez.c0re at gmail.com (c0re dumped) Date: Fri Jul 3 13:47:06 2009 Subject: Problem with vm.pmap.shpgperproc and vm.pmap.pv_entry_max Message-ID: <6dd8736a0907030618o722d8252x59479543fef23cc4@mail.gmail.com> So, I never had problem with this server, but recently it starts to giv me the following messages *every* minute : Jul 3 10:04:00 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. Jul 3 10:05:00 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. Jul 3 10:06:00 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. Jul 3 10:07:01 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. Jul 3 10:08:01 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. Jul 3 10:09:01 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. Jul 3 10:10:01 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. Jul 3 10:11:01 squid kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. This server is running Squid + dansguardian. The users are complaining about slow navigation and they are driving me crazy ! Have anyone faced this problem before ? Some infos: # uname -a FreeBSD squid 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 # sysctl vm vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: 230) Virtual Memory: (Total: 19174412K, Active 9902152K) Real Memory: (Total: 1908080K Active 1715908K) Shared Virtual Memory: (Total: 647372K Active: 10724K) Shared Real Memory: (Total: 68092K Active: 4436K) Free Memory Pages: 88372K vm.loadavg: { 0.96 0.96 1.13 } vm.v_free_min: 4896 vm.v_free_target: 20635 vm.v_free_reserved: 1051 vm.v_inactive_target: 30952 vm.v_cache_min: 20635 vm.v_cache_max: 41270 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size_scale: 3 vm.kmem_size_max: 335544320 vm.kmem_size_min: 0 vm.kmem_size: 335544320 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_async_max: 4 vm.zone_count: 84 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.exec_map_entries: 16 vm.stats.misc.zero_page_count: 0 vm.stats.misc.cnt_prezero: 0 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 340091 vm.stats.vm.v_forkpages: 3604123 vm.stats.vm.v_kthreads: 53 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 2251 vm.stats.vm.v_forks: 19295 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 41270 vm.stats.vm.v_cache_min: 20635 vm.stats.vm.v_cache_count: 5734 vm.stats.vm.v_inactive_count: 242259 vm.stats.vm.v_inactive_target: 30952 vm.stats.vm.v_active_count: 445958 vm.stats.vm.v_wire_count: 58879 vm.stats.vm.v_free_count: 16335 vm.stats.vm.v_free_min: 4896 vm.stats.vm.v_free_target: 20635 vm.stats.vm.v_free_reserved: 1051 vm.stats.vm.v_page_count: 769244 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 12442098 vm.stats.vm.v_pfree: 1657776 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 253415 vm.stats.vm.v_pdpages: 254373 vm.stats.vm.v_pdwakeups: 14 vm.stats.vm.v_reactivated: 414 vm.stats.vm.v_intrans: 1912 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 6593 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 891 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_ozfod: 56314 vm.stats.vm.v_zfod: 2016628 vm.stats.vm.v_cow_optim: 1959 vm.stats.vm.v_cow_faults: 584331 vm.stats.vm.v_vm_faults: 3661086 vm.stats.sys.v_soft: 23280645 vm.stats.sys.v_intr: 18528397 vm.stats.sys.v_syscall: 1990471112 vm.stats.sys.v_trap: 8079878 vm.stats.sys.v_swtch: 105613021 vm.stats.object.bypasses: 14893 vm.stats.object.collapses: 55259 vm.v_free_severe: 2973 vm.max_proc_mmap: 49344 vm.old_msync: 0 vm.msync_flush_flags: 3 vm.boot_pages: 48 vm.max_wired: 255475 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 vm.pageout_stats_interval: 5 vm.pageout_full_stats_interval: 20 vm.pageout_stats_max: 20635 vm.max_launder: 32 vm.phys_segs: SEGMENT 0: start: 0x1000 end: 0x9a000 free list: 0xc0cca168 SEGMENT 1: start: 0x100000 end: 0x400000 free list: 0xc0cca168 SEGMENT 2: start: 0x1025000 end: 0xbc968000 free list: 0xc0cca060 vm.phys_free: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 10 ( 4096K) | 0 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 0 | 0 7 ( 512K) | 0 | 0 6 ( 256K) | 0 | 0 5 ( 128K) | 0 | 0 4 ( 64K) | 0 | 0 3 ( 32K) | 0 | 0 2 ( 16K) | 0 | 0 1 ( 8K) | 0 | 0 0 ( 4K) | 24 | 3562 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 10 ( 4096K) | 0 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 0 | 0 7 ( 512K) | 0 | 0 6 ( 256K) | 0 | 0 5 ( 128K) | 0 | 2 4 ( 64K) | 0 | 3 3 ( 32K) | 6 | 11 2 ( 16K) | 6 | 21 1 ( 8K) | 14 | 35 0 ( 4K) | 20 | 70 vm.reserv.reclaimed: 187 vm.reserv.partpopq: LEVEL SIZE NUMBER -1: 71756K, 19 vm.reserv.freed: 35575 vm.reserv.broken: 94 vm.idlezero_enable: 0 vm.kvm_free: 310374400 vm.kvm_size: 1073737728 vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 50408 vm.pmap.pv_entry_allocs: 38854797 vm.pmap.pv_entry_frees: 37052501 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 130705 vm.pmap.pc_chunk_allocs: 136219 vm.pmap.pc_chunk_count: 5514 vm.pmap.pv_entry_count: 1802296 vm.pmap.pde.promotions: 0 vm.pmap.pde.p_failures: 0 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 0 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 2002224 vm.pmap.pg_ps_enabled: 0 Either pmap.shpgperproc and vm.pmap.pv_entry_max are with their default values. I read here (http://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/000695.html) tha its not a good ideia to increase these values arbitrarily. Thanks F?bio -- "To err is human, to blame it on somebody else shows management potential." From wojtek at wojtek.tensor.gdynia.pl Fri Jul 3 14:22:28 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Fri Jul 3 14:22:36 2009 Subject: possibly tmpfs bug Message-ID: repeatable put something on tmpfs filesystem, then download it to other machine using ftp (server is ftpd on first machine). no errors, download is fine, but you get rubbish - simply data from wrong places in memory. using rcp works. most probably ftpd uses sendfile, while rcp does not From wojtek at wojtek.tensor.gdynia.pl Fri Jul 3 14:24:18 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Fri Jul 3 14:24:25 2009 Subject: possibly tmpfs bug - part 2 In-Reply-To: References: Message-ID: works even over localhost [wojtek@wojtek /tmp]$ cp /bin/sh . [wojtek@wojtek /tmp]$ ftp localhost Trying ::1... Connected to localhost. 220 wojtek.tensor.gdynia.pl FTP server (Version 6.00LS) ready. Name (localhost:wojtek): 331 Password required for wojtek. Password: 230 User wojtek logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> get sh sh2 local: sh2 remote: sh 229 Entering Extended Passive Mode (|||59220|) 550 sh: No such file or directory. ftp> cd /tmp 250 CWD command successful. ftp> get sh sh2 local: sh2 remote: sh 229 Entering Extended Passive Mode (|||63477|) 150 Opening BINARY mode data connection for 'sh' (114688 bytes). 100% |***********************************************************| 112 KB 56.87 MB/s 00:00 ETA 226 Transfer complete. 114688 bytes received in 00:00 (51.91 MB/s) ftp> ^D 221 Goodbye. [wojtek@wojtek /tmp]$ cmp sh sh2 sh sh2 differ: char 1, line 1 From alc at cs.rice.edu Fri Jul 3 19:19:18 2009 From: alc at cs.rice.edu (Alan Cox) Date: Fri Jul 3 19:19:25 2009 Subject: large pages (amd64) In-Reply-To: References: <200906291317.12040.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4A49CBA0.1050806@cs.rice.edu> <200906301431.38664.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: <4A4E59AD.7090007@cs.rice.edu> Robert Watson wrote: > > On Tue, 30 Jun 2009, Mel Flynn wrote: > >>>> It looks like sys/kern/kern_proc.c could call mincore around the >>>> loop at line 1601 (rev 194498), but I know nothing about the vm >>>> subsystem to know the implications or locking involved. There's >>>> still 16 bytes of spare to consume, in the kve_vminfo struct though ;) >>> >>> Yes, to start with, you could replace the call to pmap_extract() >>> with a call to pmap_mincore() and export a Boolean to user space >>> that says, "This region of the address space contains one or more >>> superpage mappings." >> >> How about attached? > > I like the idea -- there are some style nits that need fixing though. > Assuming Alan is happy with the VM side of things, I can do the > cleanup and get it in the tree. Aside from the style nits, it looks good to me. Alan From to.my.trociny at gmail.com Fri Jul 3 21:41:56 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Fri Jul 3 21:42:02 2009 Subject: possibly tmpfs bug In-Reply-To: (Wojciech Puchar's message of "Fri\, 3 Jul 2009 16\:07\:56 +0200 \(CEST\)") References: Message-ID: <86skhdmokf.fsf@kopusha.onet> On Fri, 3 Jul 2009 16:07:56 +0200 (CEST) Wojciech Puchar wrote: WP> repeatable WP> put something on tmpfs filesystem, then download it to other machine WP> using ftp (server is ftpd on first machine). no errors, download is WP> fine, but you get rubbish - simply data from wrong places in memory. 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 From keramida at ceid.upatras.gr Sat Jul 4 07:17:20 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Sat Jul 4 07:17:33 2009 Subject: c question: *printf'ing arrays In-Reply-To: (Alexander Best's message of "Tue, 30 Jun 2009 20:21:03 +0200 (CEST)") References: Message-ID: <87ljn5rleb.fsf@kobe.laptop> On Tue, 30 Jun 2009 20:21:03 +0200 (CEST), Alexander Best wrote: > thanks. now the output gets redirected using >. i'm quite new to programming > under unix. sorry for the inconvenience. > > so i guess there is no really easy way to output an inhomogeneous struct to > stdout without using a loop to output each array contained in the struct. No not really. You have to do the sizeof() dance. From keramida at ceid.upatras.gr Sat Jul 4 07:17:20 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Sat Jul 4 07:17:34 2009 Subject: c question: *printf'ing arrays In-Reply-To: (Alexander Best's message of "Wed, 01 Jul 2009 00:06:05 +0200 (CEST)") References: Message-ID: <87hbxtrl0z.fsf@kobe.laptop> On Wed, 01 Jul 2009 00:06:05 +0200 (CEST), Alexander Best wrote: > thanks for all the help. i decided to take the pill and coded all the > fprintfs by hand. here's the result. usually i'd stick to a higher > level languag, but i need C's inline assembly support: > > struct Header > { > u_int8_t rom_entry[4]; > u_int8_t nintendo_logo[156]; ... > fprintf(stderr, "\nNintendo Logo: 0x"); > for (i=0; i < sizeof(hdr->nintendo_logo); i++) > fprintf(stderr, "%x", hdr->nintendo_logo[i]); Note that %x will only print *one* digit for values smaller than 16, i.e. printf("%x", 10) => "a", so it may be useful to use "%02x" instead. > fprintf(stderr, "\nFixed Value: 0x"); > fprintf(stderr, "%x", hdr->fixed_val); For multi-byte fields, it makes sense to print "0x" first and then iterate. For single-byte values, it's probably a tiny bit faster to go only _once_ through for *printf() family formatter, i.e.: - fprintf(stderr, "\nFixed Value: 0x"); - fprintf(stderr, "%x", hdr->fixed_val); + fprintf(stderr, "\nFixed Value: 0x%x", hdr->fixed_val); Another nit that I noticed is that your last line doesn't end with "\n": > fprintf(stderr, "\nJoybus Entry Point: 0x"); > for (i=0; i < sizeof(hdr->joybus_entry); i++) fprintf(stderr, "%x", > hdr->joybus_entry[i]); Some terminal setups will *not* output the last line if it does not finish properly with a "\n", so it may be worth editing the code to avoid the "\nXXX" format idiom, and go for a format style that puts "\n" at the _end_ of output lines: fprintf(stderr, "Nintendo Logo: 0x"); for (i = 0; i < sizeof(hdr->nintendo_logo); i++) fprintf(stderr, "%02x", hdr->nintendo_logo[i]); fprintf(stderr, "\n"); fprintf(stderr, "Fixed Value: 0x%02x\n", hdr->fixed_val); From igor at hybrid-lab.co.uk Sat Jul 4 08:52:56 2009 From: igor at hybrid-lab.co.uk (Igor Mozolevsky) Date: Sat Jul 4 08:53:03 2009 Subject: c question: *printf'ing arrays In-Reply-To: <87hbxtrl0z.fsf@kobe.laptop> References: <87hbxtrl0z.fsf@kobe.laptop> Message-ID: 2009/7/4 Giorgos Keramidas : [snip] s/0x%/%#.2hh/g -- Igor From xorquewasp at googlemail.com Sat Jul 4 13:13:53 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Jul 4 13:14:00 2009 Subject: bootstrapping gnat GCC on amd64 In-Reply-To: References: <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> <20090519114548.GA8610@logik.internal.network> <20090519135917.GA5391@logik.internal.network> Message-ID: <20090704130912.GA9332@logik.internal.network> Status update: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00102.html I replied to the last email in the thread but haven't heard back yet. Presumably I'll be maintaining the FreeBSD x86_64 port. I'm about to start work on the FreeBSD port now. From alexbestms at math.uni-muenster.de Sat Jul 4 22:48:48 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Jul 4 22:48:55 2009 Subject: mmap/munmap with zero length Message-ID: i'm wondering why mmap and munmap behave differently when it comes to a length argument of zero. allocating memory with mmap for a zero length file returns a valid pointer to the mapped region. munmap however isn't able to remove a mapping with no length. wouldn't it be better to either forbid this in mmap or to allow it in munmap? cheers. alex From onemda at gmail.com Sun Jul 5 00:27:50 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Jul 5 00:27:57 2009 Subject: mmap/munmap with zero length In-Reply-To: References: Message-ID: <3a142e750907041727l6fac4b67m33973ec352664c6b@mail.gmail.com> On 7/4/09, Alexander Best wrote: > i'm wondering why mmap and munmap behave differently when it comes to a > length > argument of zero. allocating memory with mmap for a zero length file returns > a > valid pointer to the mapped region. there is V flag for malloc.conf > > munmap however isn't able to remove a mapping with no length. > > wouldn't it be better to either forbid this in mmap or to allow it in > munmap? It wouldn't improve badly written program. -- Paul From neldredge at math.ucsd.edu Sun Jul 5 01:01:10 2009 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Sun Jul 5 01:01:17 2009 Subject: mmap/munmap with zero length In-Reply-To: References: Message-ID: On Sun, 5 Jul 2009, Alexander Best wrote: > i'm wondering why mmap and munmap behave differently when it comes to a length > argument of zero. allocating memory with mmap for a zero length file returns a > valid pointer to the mapped region. > > munmap however isn't able to remove a mapping with no length. > > wouldn't it be better to either forbid this in mmap or to allow it in munmap? POSIX has an opinion: http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html "If len is zero, mmap() shall fail and no mapping shall be established." http://www.opengroup.org/onlinepubs/9699919799/functions/munmap.html "The munmap() function shall fail if: ... [EINVAL] The len argument is 0." -- Nate Eldredge neldredge@math.ucsd.edu From alexbestms at math.uni-muenster.de Sun Jul 5 07:32:28 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Jul 5 07:32:36 2009 Subject: mmap/munmap with zero length In-Reply-To: Message-ID: so mmap differs from the POSIX recommendation right. the malloc.conf option seems more like a workaround/hack. imo it's confusing to have mmap und munmap deal differently with len=0. being able to succesfully alocate memory which cannot be removed doesn't seem logical to me. alex Nate Eldredge schrieb am 2009-07-05: > On Sun, 5 Jul 2009, Alexander Best wrote: > >i'm wondering why mmap and munmap behave differently when it comes > >to a length > >argument of zero. allocating memory with mmap for a zero length > >file returns a > >valid pointer to the mapped region. > >munmap however isn't able to remove a mapping with no length. > >wouldn't it be better to either forbid this in mmap or to allow it > >in munmap? > POSIX has an opinion: > http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html > "If len is zero, mmap() shall fail and no mapping shall be > established." > http://www.opengroup.org/onlinepubs/9699919799/functions/munmap.html > "The munmap() function shall fail if: > ... > [EINVAL] > The len argument is 0." > -- > Nate Eldredge > neldredge@math.ucsd.edu From yuri at rawbw.com Sun Jul 5 07:54:14 2009 From: yuri at rawbw.com (Yuri) Date: Sun Jul 5 07:54:55 2009 Subject: 'No buffer space available' messages from ral0 device Message-ID: <4A505C23.50907@rawbw.com> After I had 'wget' running for a while ral device became irresponsive and kept printing those messages: Jul 5 00:30:45 eagle dhcpcd[22608]: ral0: timed out Jul 5 00:30:45 eagle dhcpcd[22608]: ral0: lease expired 48949 seconds ago Jul 5 00:30:45 eagle dhcpcd[22608]: ral0: writev: No buffer space available Jul 5 00:31:03 eagle last message repeated 7 times Jul 5 00:31:05 eagle dhcpcd[22608]: ral0: timed out Jul 5 00:31:05 eagle dhcpcd[22608]: ral0: lease expired 48969 seconds ago Jul 5 00:31:05 eagle dhcpcd[22608]: ral0: writev: No buffer space available Jul 5 00:31:23 eagle last message repeated 7 times After I put it down/up and set it up again it worked fine again. Is this a known problem? Any workaround? Yuri From alexbestms at math.uni-muenster.de Sun Jul 5 11:42:04 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Jul 5 11:42:11 2009 Subject: carriage return with stdout and stderr Message-ID: i'm running something similar to this pseudo-code in an app of mine: for (i=0 ....) fprintf(stdout,"TEXT %d\r", int); what's really strange is that if i print to stdout the output isn't very clean. the cursor jumps randomly within the output (being 1 line). if i print to stderr however the output looks really nice. the cursor says right at the front of the output all the time. just like in burncd e.g. what's causing this? because i'd rather print to stdout. alex From jilles at stack.nl Sun Jul 5 12:05:20 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sun Jul 5 12:05:32 2009 Subject: carriage return with stdout and stderr In-Reply-To: References: Message-ID: <20090705120514.GA45921@stack.nl> On Sun, Jul 05, 2009 at 01:42:01PM +0200, Alexander Best wrote: > i'm running something similar to this pseudo-code in an app of mine: > for (i=0 ....) > fprintf(stdout,"TEXT %d\r", int); > what's really strange is that if i print to stdout the output isn't very > clean. the cursor jumps randomly within the output (being 1 line). if i print > to stderr however the output looks really nice. the cursor says right at the > front of the output all the time. just like in burncd e.g. > what's causing this? because i'd rather print to stdout. If you are writing to a terminal, stdout is line-buffered. This means that output is flushed when the buffer is full or a '\n' is written. A '\r' is not good enough. You can force a write using fflush(stdout). stderr is always unbuffered, so everything is written immediately. -- Jilles Tjoelker From christoph.mallon at gmx.de Sun Jul 5 12:20:40 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sun Jul 5 12:20:47 2009 Subject: carriage return with stdout and stderr In-Reply-To: References: Message-ID: <4A509454.3020805@gmx.de> Alexander Best schrieb: > i'm running something similar to this pseudo-code in an app of mine: > > for (i=0 ....) > fprintf(stdout,"TEXT %d\r", int); > > what's really strange is that if i print to stdout the output isn't very > clean. the cursor jumps randomly within the output (being 1 line). if i print > to stderr however the output looks really nice. the cursor says right at the > front of the output all the time. just like in burncd e.g. > > what's causing this? because i'd rather print to stdout. stdout is buffered, stderr is not. Try fflush(). Christoph From alexbestms at math.uni-muenster.de Sun Jul 5 12:20:59 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Jul 5 12:21:07 2009 Subject: carriage return with stdout and stderr In-Reply-To: <20090705120514.GA45921@stack.nl> Message-ID: thanks. i remembered fprintf being buffered, but i always thought \r would also empty the buffer. now that explains everything. ;-) alex Jilles Tjoelker schrieb am 2009-07-05: > On Sun, Jul 05, 2009 at 01:42:01PM +0200, Alexander Best wrote: > > i'm running something similar to this pseudo-code in an app of > > mine: > > for (i=0 ....) > > fprintf(stdout,"TEXT %d\r", int); > > what's really strange is that if i print to stdout the output isn't > > very > > clean. the cursor jumps randomly within the output (being 1 line). > > if i print > > to stderr however the output looks really nice. the cursor says > > right at the > > front of the output all the time. just like in burncd e.g. > > what's causing this? because i'd rather print to stdout. > If you are writing to a terminal, stdout is line-buffered. This means > that output is flushed when the buffer is full or a '\n' is written. > A > '\r' is not good enough. You can force a write using fflush(stdout). > stderr is always unbuffered, so everything is written immediately. From freebsd-listen at fabiankeil.de Sun Jul 5 16:42:47 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sun Jul 5 16:42:57 2009 Subject: Zero-length allocation with posix_memalign() Message-ID: <20090705182856.799b6b07@fabiankeil.de> I recently submitted a patch to the vlc developers that prevents a crash on FreeBSD 8.0 by not calling posix_memalign() with a size argument of zero. A simplified test case would be: #include int main(int argc, char **argv) { void *ptr; posix_memalign(&ptr, 16, 0); return (0); } which triggers: Assertion failed: (size != 0), function arena_malloc, file /usr/src/lib/libc/stdlib/malloc.c, line 3349. R?mi Denis-Courmont, one of the vlc developers, pointed out that passing a zero size to posix_memalign() should actually work, though: | In principle, while useless, there is no reason why allocating an empty | picture should not be possible. posix_memalign() does support zero-length | allocation anyway: | http://www.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html | | If the size of the space requested is 0, the behavior is | | implementation-defined; the value returned in memptr shall be either a | | null pointer or a unique pointer. http://mailman.videolan.org/pipermail/vlc-devel/2009-July/062299.html I get the impression that this deviation from the standard could be easily fixed with something similar to the following, which is mostly copy and pasted from malloc(): index 5404798..a078d07 100644 --- a/malloc.c +++ b/malloc.c @@ -5303,6 +5303,15 @@ posix_memalign(void **memptr, size_t alignment, size_t size) int ret; void *result; + if (size == 0) { + if (opt_sysv == false) + size = 1; + else { + ret = 0; + *memptr = result = NULL; + goto RETURN; + } + } if (malloc_init()) result = NULL; else { I assume the "goto RETURN" isn't entirely compliant either as it skips the alignment check, but so does the malloc_init() failure branch. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090705/d3d61ab4/signature.pgp From jasone at FreeBSD.org Sun Jul 5 17:52:01 2009 From: jasone at FreeBSD.org (Jason Evans) Date: Sun Jul 5 17:52:08 2009 Subject: Zero-length allocation with posix_memalign() In-Reply-To: <20090705182856.799b6b07@fabiankeil.de> References: <20090705182856.799b6b07@fabiankeil.de> Message-ID: <4A50E3F2.8080008@FreeBSD.org> Fabian Keil wrote: > R?mi Denis-Courmont, one of the vlc developers, pointed out > that passing a zero size to posix_memalign() should actually > work, though: > > | In principle, while useless, there is no reason why allocating an empty > | picture should not be possible. posix_memalign() does support zero-length > | allocation anyway: > | http://www.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html > | | If the size of the space requested is 0, the behavior is > | | implementation-defined; the value returned in memptr shall be either a > | | null pointer or a unique pointer. Standards: So many to choose from. This behavior for posix_memalign was only defined as of the 2008 standard (see the Issue 7 notes for posix_memalign): https://www.opengroup.org/austin/interps/uploads/40/14543/AI-152.txt Such requirements are unfortunate, because they induce a performance penalty for every call, just so that programs can avoid proper handling of edge cases in the rare situations for which such edge cases are a real possibility. I will add the pessimization to posix_memalign once the 8.0 freeze is over. It will be quite some time before this behavior becomes ubiquitous, so in the meanwhile it's probably a good idea to modify vlc to avoid such allocation requests. Thanks, Jason From onemda at gmail.com Sun Jul 5 17:56:02 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Jul 5 17:56:09 2009 Subject: Zero-length allocation with posix_memalign() In-Reply-To: <20090705182856.799b6b07@fabiankeil.de> References: <20090705182856.799b6b07@fabiankeil.de> Message-ID: <3a142e750907051056n2e1424erfb6ed75b0bb94ed2@mail.gmail.com> On 7/5/09, Fabian Keil wrote: > I recently submitted a patch to the vlc developers that prevents > a crash on FreeBSD 8.0 by not calling posix_memalign() with a > size argument of zero. > > A simplified test case would be: > > #include > int main(int argc, char **argv) { > void *ptr; > posix_memalign(&ptr, 16, 0); > return (0); > } > > which triggers: > Assertion failed: (size != 0), function arena_malloc, file > /usr/src/lib/libc/stdlib/malloc.c, line 3349. Actually that assertion is triggered only if MALLOC_PRODUCTION is undefined. (when it is undefined it considerably slows thing down) 'a' flag for malloc.conf looks broken for me .... > > Remi Denis-Courmont, one of the vlc developers, pointed out > that passing a zero size to posix_memalign() should actually > work, though: > > | In principle, while useless, there is no reason why allocating an empty > | picture should not be possible. posix_memalign() does support zero-length > | allocation anyway: > | > http://www.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html > | | If the size of the space requested is 0, the behavior is > | | implementation-defined; the value returned in memptr shall be either a > | | null pointer or a unique pointer. > http://mailman.videolan.org/pipermail/vlc-devel/2009-July/062299.html > > I get the impression that this deviation from the standard could be > easily fixed with something similar to the following, which is mostly > copy and pasted from malloc(): > > index 5404798..a078d07 100644 > --- a/malloc.c > +++ b/malloc.c > @@ -5303,6 +5303,15 @@ posix_memalign(void **memptr, size_t alignment, > size_t size) > int ret; > void *result; > > + if (size == 0) { > + if (opt_sysv == false) > + size = 1; > + else { > + ret = 0; > + *memptr = result = NULL; > + goto RETURN; > + } > + } > if (malloc_init()) > result = NULL; > else { > > I assume the "goto RETURN" isn't entirely compliant either as > it skips the alignment check, but so does the malloc_init() > failure branch. > > Fabian > -- Paul From alan.l.cox at gmail.com Sun Jul 5 19:25:28 2009 From: alan.l.cox at gmail.com (Alan Cox) Date: Sun Jul 5 19:25:35 2009 Subject: Problem with vm.pmap.shpgperproc and vm.pmap.pv_entry_max In-Reply-To: <6dd8736a0907030618o722d8252x59479543fef23cc4@mail.gmail.com> References: <6dd8736a0907030618o722d8252x59479543fef23cc4@mail.gmail.com> Message-ID: On Fri, Jul 3, 2009 at 8:18 AM, c0re dumped wrote: > So, I never had problem with this server, but recently it starts to > giv me the following messages *every* minute : > > Jul 3 10:04:00 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > Jul 3 10:05:00 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > Jul 3 10:06:00 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > Jul 3 10:07:01 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > Jul 3 10:08:01 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > Jul 3 10:09:01 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > Jul 3 10:10:01 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > Jul 3 10:11:01 squid kernel: Approaching the limit on PV entries, > consider increasing either the vm.pmap.shpgperproc or the > vm.pmap.pv_entry_max tunable. > > This server is running Squid + dansguardian. The users are complaining > about slow navigation and they are driving me crazy ! > > Have anyone faced this problem before ? > > Some infos: > > # uname -a > FreeBSD squid 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 > UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > i386 > > # sysctl vm > vm.vmtotal: > System wide totals computed every five seconds: (values in kilobytes) > =============================================== > Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: 230) > Virtual Memory: (Total: 19174412K, Active 9902152K) > Real Memory: (Total: 1908080K Active 1715908K) > Shared Virtual Memory: (Total: 647372K Active: 10724K) > Shared Real Memory: (Total: 68092K Active: 4436K) > Free Memory Pages: 88372K > > vm.loadavg: { 0.96 0.96 1.13 } > vm.v_free_min: 4896 > vm.v_free_target: 20635 > vm.v_free_reserved: 1051 > vm.v_inactive_target: 30952 > vm.v_cache_min: 20635 > vm.v_cache_max: 41270 > vm.v_pageout_free_min: 34 > vm.pageout_algorithm: 0 > vm.swap_enabled: 1 > vm.kmem_size_scale: 3 > vm.kmem_size_max: 335544320 > vm.kmem_size_min: 0 > vm.kmem_size: 335544320 > vm.nswapdev: 1 > vm.dmmax: 32 > vm.swap_async_max: 4 > vm.zone_count: 84 > vm.swap_idle_threshold2: 10 > vm.swap_idle_threshold1: 2 > vm.exec_map_entries: 16 > vm.stats.misc.zero_page_count: 0 > vm.stats.misc.cnt_prezero: 0 > vm.stats.vm.v_kthreadpages: 0 > vm.stats.vm.v_rforkpages: 0 > vm.stats.vm.v_vforkpages: 340091 > vm.stats.vm.v_forkpages: 3604123 > vm.stats.vm.v_kthreads: 53 > vm.stats.vm.v_rforks: 0 > vm.stats.vm.v_vforks: 2251 > vm.stats.vm.v_forks: 19295 > vm.stats.vm.v_interrupt_free_min: 2 > vm.stats.vm.v_pageout_free_min: 34 > vm.stats.vm.v_cache_max: 41270 > vm.stats.vm.v_cache_min: 20635 > vm.stats.vm.v_cache_count: 5734 > vm.stats.vm.v_inactive_count: 242259 > vm.stats.vm.v_inactive_target: 30952 > vm.stats.vm.v_active_count: 445958 > vm.stats.vm.v_wire_count: 58879 > vm.stats.vm.v_free_count: 16335 > vm.stats.vm.v_free_min: 4896 > vm.stats.vm.v_free_target: 20635 > vm.stats.vm.v_free_reserved: 1051 > vm.stats.vm.v_page_count: 769244 > vm.stats.vm.v_page_size: 4096 > vm.stats.vm.v_tfree: 12442098 > vm.stats.vm.v_pfree: 1657776 > vm.stats.vm.v_dfree: 0 > vm.stats.vm.v_tcached: 253415 > vm.stats.vm.v_pdpages: 254373 > vm.stats.vm.v_pdwakeups: 14 > vm.stats.vm.v_reactivated: 414 > vm.stats.vm.v_intrans: 1912 > vm.stats.vm.v_vnodepgsout: 0 > vm.stats.vm.v_vnodepgsin: 6593 > vm.stats.vm.v_vnodeout: 0 > vm.stats.vm.v_vnodein: 891 > vm.stats.vm.v_swappgsout: 0 > vm.stats.vm.v_swappgsin: 0 > vm.stats.vm.v_swapout: 0 > vm.stats.vm.v_swapin: 0 > vm.stats.vm.v_ozfod: 56314 > vm.stats.vm.v_zfod: 2016628 > vm.stats.vm.v_cow_optim: 1959 > vm.stats.vm.v_cow_faults: 584331 > vm.stats.vm.v_vm_faults: 3661086 > vm.stats.sys.v_soft: 23280645 > vm.stats.sys.v_intr: 18528397 > vm.stats.sys.v_syscall: 1990471112 > vm.stats.sys.v_trap: 8079878 > vm.stats.sys.v_swtch: 105613021 > vm.stats.object.bypasses: 14893 > vm.stats.object.collapses: 55259 > vm.v_free_severe: 2973 > vm.max_proc_mmap: 49344 > vm.old_msync: 0 > vm.msync_flush_flags: 3 > vm.boot_pages: 48 > vm.max_wired: 255475 > vm.pageout_lock_miss: 0 > vm.disable_swapspace_pageouts: 0 > vm.defer_swapspace_pageouts: 0 > vm.swap_idle_enabled: 0 > vm.pageout_stats_interval: 5 > vm.pageout_full_stats_interval: 20 > vm.pageout_stats_max: 20635 > vm.max_launder: 32 > vm.phys_segs: > SEGMENT 0: > > start: 0x1000 > end: 0x9a000 > free list: 0xc0cca168 > > SEGMENT 1: > > start: 0x100000 > end: 0x400000 > free list: 0xc0cca168 > > SEGMENT 2: > > start: 0x1025000 > end: 0xbc968000 > free list: 0xc0cca060 > > vm.phys_free: > FREE LIST 0: > > ORDER (SIZE) | NUMBER > | POOL 0 | POOL 1 > -- -- -- -- -- -- > 10 ( 4096K) | 0 | 0 > 9 ( 2048K) | 0 | 0 > 8 ( 1024K) | 0 | 0 > 7 ( 512K) | 0 | 0 > 6 ( 256K) | 0 | 0 > 5 ( 128K) | 0 | 0 > 4 ( 64K) | 0 | 0 > 3 ( 32K) | 0 | 0 > 2 ( 16K) | 0 | 0 > 1 ( 8K) | 0 | 0 > 0 ( 4K) | 24 | 3562 > > FREE LIST 1: > > ORDER (SIZE) | NUMBER > | POOL 0 | POOL 1 > -- -- -- -- -- -- > 10 ( 4096K) | 0 | 0 > 9 ( 2048K) | 0 | 0 > 8 ( 1024K) | 0 | 0 > 7 ( 512K) | 0 | 0 > 6 ( 256K) | 0 | 0 > 5 ( 128K) | 0 | 2 > 4 ( 64K) | 0 | 3 > 3 ( 32K) | 6 | 11 > 2 ( 16K) | 6 | 21 > 1 ( 8K) | 14 | 35 > 0 ( 4K) | 20 | 70 > > vm.reserv.reclaimed: 187 > vm.reserv.partpopq: > LEVEL SIZE NUMBER > > -1: 71756K, 19 > > vm.reserv.freed: 35575 > vm.reserv.broken: 94 > vm.idlezero_enable: 0 > vm.kvm_free: 310374400 > vm.kvm_size: 1073737728 > vm.pmap.pmap_collect_active: 0 > vm.pmap.pmap_collect_inactive: 0 > vm.pmap.pv_entry_spare: 50408 > vm.pmap.pv_entry_allocs: 38854797 > vm.pmap.pv_entry_frees: 37052501 > vm.pmap.pc_chunk_tryfail: 0 > vm.pmap.pc_chunk_frees: 130705 > vm.pmap.pc_chunk_allocs: 136219 > vm.pmap.pc_chunk_count: 5514 > vm.pmap.pv_entry_count: 1802296 > vm.pmap.pde.promotions: 0 > vm.pmap.pde.p_failures: 0 > vm.pmap.pde.mappings: 0 > vm.pmap.pde.demotions: 0 > vm.pmap.shpgperproc: 200 > vm.pmap.pv_entry_max: 2002224 > vm.pmap.pg_ps_enabled: 0 > > Either pmap.shpgperproc and vm.pmap.pv_entry_max are with their > default values. I read here > (http://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/000695.html) > tha its not a good ideia to increase these values arbitrarily. > There are two things that you can do: (1) Enable superpages by setting vm.pmap_pg_ps_enabled to "1" in /boot/loader.conf. A 4MB superpage mapping on i386 consumes a single PV entry instead of the 1024 entries that would be consumed by mapping 4MB of 4KB pages. Whether or not this will help depends on aspects of Squid and Dansguardian that I can't predict. (2) You shouldn't be afraid of increasing vm.pmap.pv_entry_max. However, you should watch vm.kvm_free as you do this. It will decrease in proportion to the increase in vm.pmap.pv_entry_max. Don't let vm.kvm_free drop too close to 0. I would consider too close on the order of 25-50MB. Regards, Alan From ed at 80386.nl Mon Jul 6 09:19:56 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Jul 6 09:20:04 2009 Subject: [Probably interesting for us] libcompiler_rt Message-ID: <20090706091954.GC48776@hoeg.nl> Hi all. I think I've probably mentioned dozens of times I've been working with some other people to get FreeBSD working with Clang in the base system. The LLVM people recently announced another project that may be interesting for us, which should be usable with both GCC and Clang: http://compiler-rt.llvm.org/ libcompiler_rt is a replacement for libgcc. According to the site it has some performance improvements over libgcc. I'm personally not really interested in those (as long as it's not slower), but the license seems to be a lot better. Looking at the code, it seems to do what it should do. Maybe it would just be a lot easier if we integrated all required symbols into our C library. Maybe I'm going to take a look at this, but there are also other projects which I should work on. Yours, -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090706/39e77929/attachment.pgp From des at des.no Mon Jul 6 12:14:58 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jul 6 12:15:04 2009 Subject: mmap/munmap with zero length In-Reply-To: <3a142e750907041727l6fac4b67m33973ec352664c6b@mail.gmail.com> (Paul B. Mahol's message of "Sun, 5 Jul 2009 00:27:48 +0000") References: <3a142e750907041727l6fac4b67m33973ec352664c6b@mail.gmail.com> Message-ID: <86hbxqgg8v.fsf@ds4.des.no> "Paul B. Mahol" writes: > there is V flag for malloc.conf Irrelevant. > It wouldn't improve badly written program. Allocating or mapping a zero-length region is not necessarily a bug. DES -- Dag-Erling Sm?rgrav - des@des.no From rb at gid.co.uk Mon Jul 6 13:22:25 2009 From: rb at gid.co.uk (Bob Bishop) Date: Mon Jul 6 13:22:33 2009 Subject: mmap/munmap with zero length In-Reply-To: <86hbxqgg8v.fsf@ds4.des.no> References: <3a142e750907041727l6fac4b67m33973ec352664c6b@mail.gmail.com> <86hbxqgg8v.fsf@ds4.des.no> Message-ID: Hi, On 6 Jul 2009, at 13:14, Dag-Erling Sm?rgrav wrote: > Allocating or mapping a zero-length region is not necessarily a bug. POSIX says it is, IIRC. -- Bob Bishop rb@gid.co.uk From des at des.no Mon Jul 6 13:49:21 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jul 6 13:49:28 2009 Subject: mmap/munmap with zero length In-Reply-To: (Bob Bishop's message of "Mon, 6 Jul 2009 14:05:17 +0100") References: <3a142e750907041727l6fac4b67m33973ec352664c6b@mail.gmail.com> <86hbxqgg8v.fsf@ds4.des.no> Message-ID: <86d48dhqg1.fsf@ds4.des.no> Bob Bishop writes: > Dag-Erling Sm?rgrav writes: > > Allocating or mapping a zero-length region is not necessarily a bug. > POSIX says it is, IIRC. For mmap(), yes; for malloc(), no. DES -- Dag-Erling Sm?rgrav - des@des.no From freebsd-listen at fabiankeil.de Mon Jul 6 18:26:19 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Mon Jul 6 18:26:27 2009 Subject: Zero-length allocation with posix_memalign() In-Reply-To: <4A50E3F2.8080008@FreeBSD.org> References: <20090705182856.799b6b07@fabiankeil.de> <4A50E3F2.8080008@FreeBSD.org> Message-ID: <20090706202608.45c98821@fabiankeil.de> Jason Evans wrote: > Fabian Keil wrote: > > R?mi Denis-Courmont, one of the vlc developers, pointed out > > that passing a zero size to posix_memalign() should actually > > work, though: > > > > | In principle, while useless, there is no reason why allocating an empty > > | picture should not be possible. posix_memalign() does support zero-length > > | allocation anyway: > > | http://www.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html > > | | If the size of the space requested is 0, the behavior is > > | | implementation-defined; the value returned in memptr shall be either a > > | | null pointer or a unique pointer. > > Standards: So many to choose from. This behavior for posix_memalign was > only defined as of the 2008 standard (see the Issue 7 notes for > posix_memalign): > > https://www.opengroup.org/austin/interps/uploads/40/14543/AI-152.txt > > Such requirements are unfortunate, because they induce a performance > penalty for every call, just so that programs can avoid proper handling > of edge cases in the rare situations for which such edge cases are a > real possibility. > > I will add the pessimization to posix_memalign once the 8.0 freeze is > over. It will be quite some time before this behavior becomes > ubiquitous, so in the meanwhile it's probably a good idea to modify vlc > to avoid such allocation requests. Great, thanks. I agree and will forward the vlc patch to the maintainer of the FreeBSD port if getting it committed upstream fails. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090706/13df339a/signature.pgp From jawa2502 at gmail.com Wed Jul 8 08:09:11 2009 From: jawa2502 at gmail.com (Jawahar Tadipatri) Date: Wed Jul 8 08:09:17 2009 Subject: Regarding IO to disk Message-ID: <995877b70907080042he7aee18m22f9d4a0e4b18bef@mail.gmail.com> Hi Folks,Can anyone please let me know the average/typical time taken for completing one IO operation (read and write) to disk? More specifically, time taken for writing a string to a file. Thanks a load, Jawahar From ivoras at freebsd.org Wed Jul 8 11:35:37 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Jul 8 11:35:44 2009 Subject: Regarding IO to disk In-Reply-To: <995877b70907080042he7aee18m22f9d4a0e4b18bef@mail.gmail.com> References: <995877b70907080042he7aee18m22f9d4a0e4b18bef@mail.gmail.com> Message-ID: Jawahar Tadipatri wrote: > Hi Folks,Can anyone please let me know the average/typical time taken for > completing one IO operation (read and write) to disk? > More specifically, time taken for writing a string to a file. Your question is incomplete and cannot be answered correctly. Declared average latency for desktop hard drives (see http://www.seagate.com/docs/pdf/datasheet/disc/ds_barracuda_7200_12.pdf) is about 4 ms. Real performance depends on about a dozen factors. See here: http://www.google.com/search?q=hard+drive+performance for more information. From jawa2502 at gmail.com Wed Jul 8 12:02:24 2009 From: jawa2502 at gmail.com (Jawahar Tadipatri) Date: Wed Jul 8 12:02:31 2009 Subject: Regarding IO to disk In-Reply-To: References: <995877b70907080042he7aee18m22f9d4a0e4b18bef@mail.gmail.com> Message-ID: <995877b70907080502k64c6bf65n448cd91cb7f85d1@mail.gmail.com> Thanks for the info Ivan. On Wed, Jul 8, 2009 at 5:05 PM, Ivan Voras wrote: > Jawahar Tadipatri wrote: > >> Hi Folks,Can anyone please let me know the average/typical time taken for >> completing one IO operation (read and write) to disk? >> More specifically, time taken for writing a string to a file. >> > > Your question is incomplete and cannot be answered correctly. > > Declared average latency for desktop hard drives (see > http://www.seagate.com/docs/pdf/datasheet/disc/ds_barracuda_7200_12.pdf) > is about 4 ms. Real performance depends on about a dozen factors. > > See here: http://www.google.com/search?q=hard+drive+performance for more > information. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From wojtek at wojtek.tensor.gdynia.pl Wed Jul 8 15:54:39 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Wed Jul 8 15:54:47 2009 Subject: Regarding IO to disk In-Reply-To: References: <995877b70907080042he7aee18m22f9d4a0e4b18bef@mail.gmail.com> Message-ID: > > Declared average latency for desktop hard drives (see > http://www.seagate.com/docs/pdf/datasheet/disc/ds_barracuda_7200_12.pdf) is latency is average time to wait until data will be below head. it's by average half on single rotation. for 7200 rpm drive it's 120rps so half rotation takes 1/240 second=about 4ms. But to perform I/O you have to - send a request to disk (<1ms) - move head - depends of distance, up to 20-30ms, 8-10ms average on most drives - wait for latency - 4ms average. you end in 13-15ms average. in case of multiple parallel accesses - drive accept writes immediatelly, and can accept multiple reads if it can NCQ/TCQ, then it internally sort request queue to minimize required head moves and rotational waiting, so under high load you may go to 6-7ms/request which is about 150IOPS. Of course i'm talking about random/pseudorandom reads, multiple reads of sequential addresses will be optimized by drive. One more - i'm talking about raw I/O, FreeBSD of course optimizes filesystem acces internally by using lots of caching (as much as available memory) and planning requests. small writes to file usually succeed immediatelly (to cache). From wojtek at wojtek.tensor.gdynia.pl Wed Jul 8 15:56:19 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Wed Jul 8 15:56:25 2009 Subject: What's changed between 7.1 and 7.2 Message-ID: i'm getting that crap every time i remount filesystem and on startup. GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. i'm using glabel only to avoid mess about what drive is connected to what SATA port. From chflags at gmail.com Wed Jul 8 16:23:35 2009 From: chflags at gmail.com (Kevin Foo) Date: Wed Jul 8 16:23:43 2009 Subject: Regression in atkbd? In-Reply-To: <25cb30907080911i2fb3026dq5cf980848c0cd2a8@mail.gmail.com> References: <25cb30907080911i2fb3026dq5cf980848c0cd2a8@mail.gmail.com> Message-ID: <25cb30907080915l40dd3e81q9790a0b261cca143@mail.gmail.com> On Thu, Jul 9, 2009 at 12:11 AM, Kevin Foo wrote: > Hi list, > > Did anyone experience issue with atkbd on 8.0? I encountered issue > with keyboard and touchpad on HP presario V3400 when trying to upgrade > from 7.2-RELEASE to 8.0 prior to and on BETA1.The keyboard and > touchpad are working fine on 7.2. On 8.0 prior to BETA1, I managed to > obtain dmesg via ssh despite having a non-operational keyboard. The > laptop was totally inaccessible on 8.0 BETA1 as it freezed after the > line atkbdc0. No information could be obtained. > > Any ideas? Please let me know if you require more information. Thanks. > > /boot/device.hints (default, no changes made) > hint.atkbdc.0.at="isa" > hint.atkbdc.0.port="0x060" > hint.atkbd.0.at="atkbdc" > hint.atkbd.0.irq="1" > hint.psm.0.at="atkbdc" > hint.psm.0.irq="12" > > 1) FreeBSD 8.0-BETA1 amd64 as of today with GENERIC kernel:- > <---snip---< > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > system hangs...... > > > 2) FreeBSD 8.0-CURRENT amd64 prior to BETA1 custom kernel without > debug/invariant/witness:- > <---snip---< > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: unable to set the command byte. > kbd0 at atkbd0 > kbd0: atkbd0, generic (0), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0047 > psm0: unable to set the command byte. > <---snip---< > Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.8.txt > > > 3) FreeBSD 7.2-RELEASE-p2 amd64:- > <---snip---< > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0047 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > <---snip---< > Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.7.txt > > -- > Regards > Kevin Foo > Also, setting hint.atkbd.0.flags 0x01, 0x09, 0x02 on boot loader did not help. -- Regards Kevin Foo From olivier at gid0.org Wed Jul 8 16:31:10 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Wed Jul 8 16:31:18 2009 Subject: What's changed between 7.1 and 7.2 In-Reply-To: References: Message-ID: <367b2c980907080902t1a5ae82by6e6d088e619bfc92@mail.gmail.com> 2009/7/8 Wojciech Puchar : > i'm getting that crap every time i remount filesystem and on startup. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. Hello, I posted something similar few weeks ago : http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005546.html > i'm using glabel only to avoid mess about what drive is connected to what > SATA port. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From chflags at gmail.com Wed Jul 8 16:41:45 2009 From: chflags at gmail.com (Kevin Foo) Date: Wed Jul 8 16:41:52 2009 Subject: Regression in atkbd? Message-ID: <25cb30907080911i2fb3026dq5cf980848c0cd2a8@mail.gmail.com> Hi list, Did anyone experience issue with atkbd on 8.0? I encountered issue with keyboard and touchpad on HP presario V3400 when trying to upgrade from 7.2-RELEASE to 8.0 prior to and on BETA1.The keyboard and touchpad are working fine on 7.2. On 8.0 prior to BETA1, I managed to obtain dmesg via ssh despite having a non-operational keyboard. The laptop was totally inaccessible on 8.0 BETA1 as it freezed after the line atkbdc0. No information could be obtained. Any ideas? Please let me know if you require more information. Thanks. /boot/device.hints (default, no changes made) hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" 1) FreeBSD 8.0-BETA1 amd64 as of today with GENERIC kernel:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 system hangs...... 2) FreeBSD 8.0-CURRENT amd64 prior to BETA1 custom kernel without debug/invariant/witness:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: unable to set the command byte. kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: unable to set the command byte. <---snip---< Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.8.txt 3) FreeBSD 7.2-RELEASE-p2 amd64:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 <---snip---< Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.7.txt -- Regards Kevin Foo From rwatson at FreeBSD.org Wed Jul 8 17:28:25 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jul 8 17:28:32 2009 Subject: What's changed between 7.1 and 7.2 In-Reply-To: References: Message-ID: On Wed, 8 Jul 2009, Wojciech Puchar wrote: > i'm getting that crap every time i remount filesystem and on startup. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. > GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. > GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. > > i'm using glabel only to avoid mess about what drive is connected to what > SATA port. This is effectively debugging output that slipped into the release and shouldn't have. I believe it's now removed in 8.x, I'm not sure it's been MFC'd to 7.x yet. The output can be entirely ignored and does not reflect a problem, just state changes resulting from a volume becoming visible to geom, and then the label name being removed following mount. Robert N M Watson Computer Laboratory University of Cambridge From dimitry at andric.com Wed Jul 8 17:55:17 2009 From: dimitry at andric.com (Dimitry Andric) Date: Wed Jul 8 17:55:23 2009 Subject: What's changed between 7.1 and 7.2 In-Reply-To: References: Message-ID: <4A54DD82.50900@andric.com> On 2009-07-08 19:28, Robert Watson wrote: > This is effectively debugging output that slipped into the release and > shouldn't have. I believe it's now removed in 8.x, I'm not sure it's been > MFC'd to 7.x yet. It was indeed removed, with r193131. The diff here: http://svn.freebsd.org/viewvc/base/head/sys/geom/label/g_label.c?view=patch&r1=193131&r2=193130&pathrev=193131 should apply to 7.x without problems. From alexbestms at math.uni-muenster.de Thu Jul 9 04:09:25 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Jul 9 04:09:32 2009 Subject: mmap/munmap with zero length In-Reply-To: Message-ID: so. doesn't that mean that actually freebsd's mmap implementation needs to be changed in order to return an error if one tries to allocate space with len=0? alex Bob Bishop schrieb am 2009-07-06: > Hi, > On 6 Jul 2009, at 13:14, Dag-Erling Sm?rgrav wrote: > >Allocating or mapping a zero-length region is not necessarily a bug. > POSIX says it is, IIRC. > -- > Bob Bishop > rb@gid.co.uk From alexbestms at math.uni-muenster.de Thu Jul 9 04:11:03 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Jul 9 04:11:11 2009 Subject: c question: *printf'ing arrays In-Reply-To: Message-ID: thx for all the great help guys. cheers, alex Carlos A. M. dos Santos schrieb am 2009-07-02: > 2009/7/2 Dag-Erling Sm?rgrav : > > Alexander Best writes: > >> ? ? for (i=0; i < sizeof(hdr->nintendo_logo); i++) > >> ? ? ? ? fprintf(stderr, "%x", hdr->nintendo_logo[i]); > > What will this print if nintendo_logo is { 0x01, 0x02, 0x03, 0x04 > > }? > Good catch. It will print "0x1234" but it should print "0x01020304". > My example has the same error. The conversion specification should be > "%02x", not just "%x". From nick at van-laarhoven.org Thu Jul 9 11:50:32 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Thu Jul 9 11:50:49 2009 Subject: What's changed between 7.1 and 7.2 In-Reply-To: <4A54DD82.50900@andric.com> References: <4A54DD82.50900@andric.com> Message-ID: <200907091333.35829.nick@van-laarhoven.org> The debugging printf has been changed to not print anything if debuglevel is 0. Nick > On 2009-07-08 19:28, Robert Watson wrote: > > This is effectively debugging output that slipped into the release and > > shouldn't have. I believe it's now removed in 8.x, I'm not sure it's > > been MFC'd to 7.x yet. > > It was indeed removed, with r193131. The diff here: > > http://svn.freebsd.org/viewvc/base/head/sys/geom/label/g_label.c?view=pat >ch&r1=193131&r2=193130&pathrev=193131 > > should apply to 7.x without problems. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From brian at FreeBSD.org Fri Jul 10 03:27:21 2009 From: brian at FreeBSD.org (Brian Somers) Date: Fri Jul 10 03:27:29 2009 Subject: make {,re}installkernel{,.debug} Message-ID: <20090709195915.35556269@dev.lan.Awfulhak.org> Hi, I'd like to change the way ``make {,re}installkernel{,.debug}'' works. Currently we have this: - GENERIC contains ``makeoptions DEBUG=-g''. This puts DEBUG=-g into /usr/obj/usr/src/sys/GENERIC/Makefile - ``make {,re}installkernel'' installs *.ko.symbols if DEBUG is set (which it is - as per above). - ``make {,re}installkernel'' ignores *.ko.symbols if INSTALL_NODEBUG is set. - ``make {,re}installkernel.debug'' does the same as the non-.debug version but if DEBUG is defined, also installs .gdbinit and support files into /usr/obj/usr/src/sys/GENERIC/. I find this a little odd. My proposed change (see below) does this: - GENERIC contains ``makeoptions DEBUG=-g'' as before. - ``make {,re}installkernel'' ignores *.ko.symbols - ``make {,re}installkernel.debug'' installs *.ko.symbols and puts .gdbinit & friends into /usr/obj/usr/src/sys/GENERIC/ as before - if available (ie., if DEBUG is set). - INSTALL_NODEBUG goes away. I think this is much clearer. The net result would be that those of us who currently "make installkernel" will go back to having no symbol files (as was the case in FreeBSD-6 if INSTALL_DEBUG wasn't defined). One might argue that *not* installing .gdbinit & friends into a kernel object directory that has symbols is a mistake, but AFAIR that conversation included too many opinions last time it was discussed. Opinions? Index: tools/tools/nanobsd/gateworks/common =================================================================== --- tools/tools/nanobsd/gateworks/common (revision 195527) +++ tools/tools/nanobsd/gateworks/common (working copy) @@ -156,7 +156,6 @@ install_kernel() cd ${NANO_SRC} env TARGET_ARCH=${NANO_ARCH} ${NANO_PMAKE} installkernel \ - INSTALL_NODEBUG=true \ DESTDIR=${NANO_WORLDDIR} \ __MAKE_CONF=${NANO_MAKE_CONF} KERNCONF=`basename ${NANO_KERNEL}` \ > ${MAKEOBJDIRPREFIX}/_.ik 2>&1 Index: sys/conf/kern.post.mk =================================================================== --- sys/conf/kern.post.mk (revision 195516) +++ sys/conf/kern.post.mk (working copy) @@ -18,13 +18,13 @@ MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" SYSDIR="$ .MAIN: all .for target in all clean cleandepend cleandir clobber depend install \ - obj reinstall tags + install.debug obj reinstall reinstall.debug tags ${target}: kernel-${target} .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) ${target}: modules-${target} modules-${target}: cd $S/modules; ${MKMODULESENV} ${MAKE} \ - ${target:S/^reinstall$/install/:S/^clobber$/cleandir/} + ${target:S/^reinstall$/install/:S/^reinstall.debug$/install.debug/:S/^clobber$/cleandir/} .endif .endfor @@ -69,7 +69,6 @@ ${KERNEL_KO}: ${FULLKERNEL} ${KERNEL_KO}.symbols ${KERNEL_KO}.symbols: ${FULLKERNEL} ${OBJCOPY} --only-keep-debug ${FULLKERNEL} ${.TARGET} install.debug reinstall.debug: gdbinit - cd ${.CURDIR}; ${MAKE} ${.TARGET:R} # Install gdbinit files for kernel debugging. gdbinit: @@ -197,7 +196,7 @@ kernel-tags: @[ -f .depend ] || { echo "you must make depend first"; exit 1; } sh $S/conf/systags.sh -kernel-install: +kernel-install kernel-install.debug: @if [ ! -f ${KERNEL_KO} ] ; then \ echo "You must build a kernel first." ; \ exit 1 ; \ @@ -218,7 +217,7 @@ kernel-tags: .endif mkdir -p ${DESTDIR}${KODIR} ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_KO} ${DESTDIR}${KODIR} -.if defined(DEBUG) && !defined(INSTALL_NODEBUG) +.if defined(DEBUG) && ${.TARGET:E} == .debug ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_KO}.symbols ${DESTDIR}${KODIR} .endif .if defined(KERNEL_EXTRA_INSTALL) @@ -227,10 +226,10 @@ kernel-tags: -kernel-reinstall: +kernel-reinstall kernel-reinstall.debug: @-chflags -R noschg ${DESTDIR}${KODIR} ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_KO} ${DESTDIR}${KODIR} -.if defined(DEBUG) && !defined(INSTALL_NODEBUG) +.if defined(DEBUG) && ${.TARGET:E} == .debug ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_KO}.symbols ${DESTDIR}${KODIR} .endif Index: sys/conf/kmod.mk =================================================================== --- sys/conf/kmod.mk (revision 195516) +++ sys/conf/kmod.mk (working copy) @@ -46,6 +46,10 @@ # # +++ targets +++ # +# install.debug: +# Depends on install, then installs the kernel module with +# symbols. +# # install: # install the kernel module; if the Makefile # does not itself define the target install, the targets @@ -269,10 +273,6 @@ realinstall: _kmodinstall _kmodinstall: ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \ ${_INSTALLFLAGS} ${PROG} ${DESTDIR}${KMODDIR} -.if defined(DEBUG_FLAGS) && !defined(INSTALL_NODEBUG) - ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \ - ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR} -.endif .include @@ -290,6 +290,16 @@ _kldxref: .endif # !target(install) +.if !target(install.debug) +install.debug: +.if defined(DEBUG_FLAGS) + ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \ + ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR} +.endif +.endif # !target(install.debug) + +install.debug: install + .if !target(load) load: ${PROG} ${KMODLOAD} -v ${.OBJDIR}/${PROG} Index: UPDATING =================================================================== --- UPDATING (revision 195527) +++ UPDATING (working copy) @@ -22,6 +22,11 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 8.x IS SLOW: to maximize performance. (To disable malloc debugging, run ln -s aj /etc/malloc.conf.) +20090709: + The use of INSTALL_NODEBUG has been deprecated and symbol files + are no longer installed by default. To install kernel and + module symbol files, use the {,re}installkernel.debug target. + 20090630: The NFS_LEGACYRPC option has been removed along with the old kernel RPC implementation that this option selected. Kernel Index: Makefile =================================================================== --- Makefile (revision 195527) +++ Makefile (working copy) @@ -11,9 +11,9 @@ # world - buildworld + installworld, no kernel. # buildkernel - Rebuild the kernel and the kernel-modules. # installkernel - Install the kernel and the kernel-modules. -# installkernel.debug +# installkernel.debug - Also install kernel and module symbols. # reinstallkernel - Reinstall the kernel and the kernel-modules. -# reinstallkernel.debug +# reinstallkernel.debug - Also reinstall kernel and module symbols. # kernel - buildkernel + installkernel. # doxygen - Build API documentation of the kernel, needs doxygen. # update - Convenient way to update your source tree (cvs). Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 195527) +++ Makefile.inc1 (working copy) @@ -682,6 +682,9 @@ distrib-dirs distribution: # for building kernels and only the first of these is designated # as the one being installed. # +# If your kernel is built with DEBUG set, installkernel.debug +# will additionally install kernel and module symbols. +# # Note that we have to use TARGET instead of TARGET_ARCH when # we're in kernel-land. Since only TARGET_ARCH is (expected) to # be set to cross-build, we have to make sure TARGET is set Index: share/mk/bsd.subdir.mk =================================================================== --- share/mk/bsd.subdir.mk (revision 195516) +++ share/mk/bsd.subdir.mk (working copy) @@ -67,7 +67,7 @@ ${SUBDIR}: .PHONY .for __target in all all-man checkdpadd clean cleandepend cleandir \ depend distribute lint maninstall manlint \ - obj objlink realinstall regress tags \ + obj objlink realinstall install.debug regress tags \ ${SUBDIR_TARGETS} ${__target}: _SUBDIR .endfor -- Brian Somers Don't _EVER_ lose your sense of humour ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090710/0556e7aa/signature.pgp From ivoras at freebsd.org Fri Jul 10 09:52:45 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Jul 10 09:52:53 2009 Subject: What's changed between 7.1 and 7.2 In-Reply-To: References: Message-ID: Robert Watson wrote: > > On Wed, 8 Jul 2009, Wojciech Puchar wrote: > >> i'm getting that crap every time i remount filesystem and on startup. >> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >> >> i'm using glabel only to avoid mess about what drive is connected to >> what SATA port. > > This is effectively debugging output that slipped into the release and > shouldn't have. I believe it's now removed in 8.x, I'm not sure it's > been MFC'd to 7.x yet. The output can be entirely ignored and does not > reflect a problem, just state changes resulting from a volume becoming > visible to geom, and then the label name being removed following mount. If it's desireable to MFC it now, I'll do it. (but it will remove the above output for all glabel labels, not only ufs). From rwatson at FreeBSD.org Fri Jul 10 11:08:59 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Jul 10 11:09:10 2009 Subject: What's changed between 7.1 and 7.2 In-Reply-To: References: Message-ID: On Fri, 10 Jul 2009, Ivan Voras wrote: > Robert Watson wrote: >> >> On Wed, 8 Jul 2009, Wojciech Puchar wrote: >> >>> i'm getting that crap every time i remount filesystem and on startup. >>> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >>> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >>> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >>> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >>> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >>> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >>> GEOM_LABEL: Label ufsid/48dd2cbe8423dd9e removed. >>> GEOM_LABEL: Label for provider mirror/sysa is ufsid/48dd2cbe8423dd9e. >>> >>> i'm using glabel only to avoid mess about what drive is connected to what >>> SATA port. >> >> This is effectively debugging output that slipped into the release and >> shouldn't have. I believe it's now removed in 8.x, I'm not sure it's been >> MFC'd to 7.x yet. The output can be entirely ignored and does not reflect >> a problem, just state changes resulting from a volume becoming visible to >> geom, and then the label name being removed following mount. > > If it's desireable to MFC it now, I'll do it. > > (but it will remove the above output for all glabel labels, not only ufs). I think it would be widely appreciated. :-) Robert N M Watson Computer Laboratory University of Cambridge From hdante at gmail.com Sun Jul 12 19:45:14 2009 From: hdante at gmail.com (Henrique Almeida) Date: Sun Jul 12 19:45:21 2009 Subject: Help on relicensing derived code Message-ID: Hello, I have a doubt about licensing, please refer to the correct mailing list if I've sent to the wrong one. I need to write an "errno.h" with constant values used by the FreeBSD kernel. My project uses exclusively the 2 clause BSD license. I expected to copy those values from FreeBSD errno.h. However, FreeBSD errno.h has 3 clauses. I'm a total newbie in licensing procedures so, it's not clear what to do. - Relicense the code as a 2 license BSD, because it's a derived work (prefered choice) - If the above is not allowed, ask the original authors of errno.h to provide an alternative 2 clause BSD license. Which choice is legally correct ? -- Henrique Dante de Almeida hdante@gmail.com From wojtek at wojtek.tensor.gdynia.pl Sun Jul 12 20:50:15 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Sun Jul 12 20:50:23 2009 Subject: What's changed between 7.1 and 7.2 In-Reply-To: References: Message-ID: >> i'm using glabel only to avoid mess about what drive is connected to what >> SATA port. > > This is effectively debugging output that slipped into the release and > shouldn't have. I believe it's now removed in 8.x, I'm not sure it's been > MFC'd to 7.x yet. The output can be entirely ignored and does not reflect a > problem, just state changes resulting from a volume becoming visible to geom, > and then the label name being removed following mount. > just commented it out from source ;) thanks From unixmania at gmail.com Mon Jul 13 04:24:56 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Mon Jul 13 04:25:02 2009 Subject: Help on relicensing derived code In-Reply-To: References: Message-ID: On Sun, Jul 12, 2009 at 4:20 PM, Henrique Almeida wrote: > I need to write an "errno.h" with constant values used by the FreeBSD > kernel. My project uses exclusively the 2 clause BSD license. I > expected to copy those values from FreeBSD errno.h. However, FreeBSD > errno.h has 3 clauses.[...] Do you have any particular reason to refuse the current 3-clause license? >[...] I'm a total newbie in licensing procedures so, > it's not clear what to do. > > - Relicense the code as a 2 license BSD, because it's a derived work > (prefered choice) You can't do that. The copyright owners are The Regents of the University of California and UNIX System Laboratories (now Novell). Changing the license without their permission would be legally considered theft. > - If the above is not allowed, ask the original authors of errno.h to > provide an alternative 2 clause BSD license. You must ask the copyright owners, UC and Novell. I don't believe you will have success any time soon, however. > Which choice is legally correct ? The second one, but I strongly advise you to adopt the file as is. The license is already fairly liberal. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From sebastian.huber at embedded-brains.de Mon Jul 13 09:41:03 2009 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Mon Jul 13 09:41:10 2009 Subject: Return type of xpt_bus_register() and xpt_bus_deregister() Message-ID: <4A5AFD0B.2060207@embedded-brains.de> Hi, why have the functions xpt_bus_register() and xpt_bus_unregister() a return value type of int32_t? For me it is not clear how the supposed return value should look like. They return a mixture of cam_status and CAM_SUCCESS (this one equals CAM_REQ_INPROG). Have a nice day! -- Sebastian Huber, Embedded Brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From hdante at gmail.com Mon Jul 13 12:57:50 2009 From: hdante at gmail.com (Henrique Almeida) Date: Mon Jul 13 12:57:57 2009 Subject: Fwd: Help on relicensing derived code In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Henrique Almeida Date: 2009/7/13 Subject: Re: Help on relicensing derived code To: "Carlos A. M. dos Santos" 2009/7/13 Carlos A. M. dos Santos : > On Sun, Jul 12, 2009 at 4:20 PM, Henrique Almeida wrote: > >> ?I need to write an "errno.h" with constant values used by the FreeBSD >> kernel. My project uses exclusively the 2 clause BSD license. I >> expected to copy those values from FreeBSD errno.h. However, FreeBSD >> errno.h has 3 clauses.[...] > > Do you have any particular reason to refuse the current 3-clause license? ?Yes, I've decided to choose uniform licensing for the whole project. I think it will be better for users this way. I'll try to stick with that unless completelly impossible. > >>[...] I'm a total newbie in licensing procedures so, >> it's not clear what to do. >> >> ?- Relicense the code as a 2 license BSD, because it's a derived work >> (prefered choice) > > You can't do that. The copyright owners are The Regents of the > University of California and UNIX System Laboratories (now Novell). > Changing the license without their permission would be legally > considered theft. ?Notice that I won't relicense the original code. I only need to relicense the derived work (my own version of errno.h), as described in the copyright law section of the following link: ?http://www.openbsd.org/policy.html ?Maybe we could find a lawyer to explain that. :-/ > >> ?- If the above is not allowed, ask the original authors of errno.h to >> provide an alternative 2 clause BSD license. > > You must ask the copyright owners, UC and Novell. I don't believe you > will have success any time soon, however. > >> ?Which choice is legally correct ? > > The second one, but I strongly advise you to adopt the file as is. The > license is already fairly liberal. ?Please answer again, given the comment above. :-) I still have hope I can use a 2 clause license. > > -- > My preferred quotation of Robert Louis Stevenson is "You cannot > make an omelette without breaking eggs". Not because I like the > omelettes, but because I like the sound of eggs being broken. > -- ?Henrique Dante de Almeida ?hdante@gmail.com -- Henrique Dante de Almeida hdante@gmail.com From hdante at gmail.com Mon Jul 13 13:23:54 2009 From: hdante at gmail.com (Henrique Almeida) Date: Mon Jul 13 13:24:01 2009 Subject: Help on relicensing derived code In-Reply-To: References: Message-ID: Good news, in Android errno, there's a statement that suggests that constant values are not copyrightable. :-) http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=libc/kernel/common/asm-generic/errno-base.h;h=2fb4a336454e47f8bf0764fd253a78be633f9652;hb=HEAD /**************************************************************************** **************************************************************************** *** *** This header was automatically generated from a Linux kernel header *** of the same name, to make information necessary for userspace to *** call into the kernel available to libc. It contains only constants, *** structures, and macros generated from the original header, and thus, *** contains no copyrightable information. *** **************************************************************************** ****************************************************************************/ But does this mean I can copy those values without using an automated procedure ? Damned licensing hell. 2009/7/13 Henrique Almeida : > ---------- Forwarded message ---------- > From: Henrique Almeida > Date: 2009/7/13 > Subject: Re: Help on relicensing derived code > To: "Carlos A. M. dos Santos" > > > 2009/7/13 Carlos A. M. dos Santos : >> On Sun, Jul 12, 2009 at 4:20 PM, Henrique Almeida wrote: >> >>> ?I need to write an "errno.h" with constant values used by the FreeBSD >>> kernel. My project uses exclusively the 2 clause BSD license. I >>> expected to copy those values from FreeBSD errno.h. However, FreeBSD >>> errno.h has 3 clauses.[...] >> >> Do you have any particular reason to refuse the current 3-clause license? > > ?Yes, I've decided to choose uniform licensing for the whole project. > I think it will be better for users this way. I'll try to stick with > that unless completelly impossible. > >> >>>[...] I'm a total newbie in licensing procedures so, >>> it's not clear what to do. >>> >>> ?- Relicense the code as a 2 license BSD, because it's a derived work >>> (prefered choice) >> >> You can't do that. The copyright owners are The Regents of the >> University of California and UNIX System Laboratories (now Novell). >> Changing the license without their permission would be legally >> considered theft. > > ?Notice that I won't relicense the original code. I only need to > relicense the derived work (my own version of errno.h), as described > in the copyright law section of the following link: > > ?http://www.openbsd.org/policy.html > > ?Maybe we could find a lawyer to explain that. :-/ > >> >>> ?- If the above is not allowed, ask the original authors of errno.h to >>> provide an alternative 2 clause BSD license. >> >> You must ask the copyright owners, UC and Novell. I don't believe you >> will have success any time soon, however. >> >>> ?Which choice is legally correct ? >> >> The second one, but I strongly advise you to adopt the file as is. The >> license is already fairly liberal. > > ?Please answer again, given the comment above. :-) I still have hope I > can use a 2 clause license. > >> >> -- >> My preferred quotation of Robert Louis Stevenson is "You cannot >> make an omelette without breaking eggs". Not because I like the >> omelettes, but because I like the sound of eggs being broken. >> > > > > -- > ?Henrique Dante de Almeida > ?hdante@gmail.com > > > > -- > ?Henrique Dante de Almeida > ?hdante@gmail.com > -- Henrique Dante de Almeida hdante@gmail.com From unixmania at gmail.com Mon Jul 13 13:26:32 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Mon Jul 13 13:26:40 2009 Subject: Help on relicensing derived code In-Reply-To: References: Message-ID: On Mon, Jul 13, 2009 at 9:57 AM, Henrique Almeida wrote: > 2009/7/13 Carlos A. M. dos Santos : >> On Sun, Jul 12, 2009 at 4:20 PM, Henrique Almeida wrote: >>> ?I need to write an "errno.h" with constant values used by the FreeBSD >>> kernel. My project uses exclusively the 2 clause BSD license. I >>> expected to copy those values from FreeBSD errno.h. However, FreeBSD >>> errno.h has 3 clauses.[...] >> >> Do you have any particular reason to refuse the current 3-clause license? > > ?Yes, I've decided to choose uniform licensing for the whole project. > I think it will be better for users this way. I still don't see the point. The advertising clause was removed ten years ago and the remaining 3 clauses impose just a few restrictions. > I'll try to stick with that unless completelly impossible. You can choose any license for code owned by you. You can also relicense BSD-licensed code, but you still must either obey the original license or obtain written permission to change the terms [from the original copyright owner, University of Californa and USL/Novell, not the FreeBSD project]. Take a look at http://www.groklaw.net/articlebasic.php?story=20070114093427179 > Notice that I won't relicense the original code. I only need to > relicense the derived work (my own version of errno.h), as described > in the copyright law section of the following link: > > ?http://www.openbsd.org/policy.html If you are writing your own version of errno.h then it is not a derived work. In this particular case, errno.h is just a list of error codes so you can copy/paste the numbers and mnemonics from the output of "man 2 intro". That would be considered "compatible code", not derived work. Please refer to the last two paragraphs of the "Pretrial" section at http://en.wikipedia.org/wiki/USL_v._BSDi#Pretrial > ?Maybe we could find a lawyer to explain that. :-/ May be you could just accept the current license and avoid the pain. ;-) -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From hdante at gmail.com Mon Jul 13 13:39:56 2009 From: hdante at gmail.com (Henrique Almeida) Date: Mon Jul 13 13:40:03 2009 Subject: Help on relicensing derived code In-Reply-To: References: Message-ID: 2009/7/13 Carlos A. M. dos Santos : > If you are writing your own version of errno.h then it is not a > derived work. In this particular case, errno.h is just a list of error > codes so you can copy/paste the numbers and mnemonics from the output > of "man 2 intro". That would be considered "compatible code", not Perfect. I told you I would be able to use uniform licensing. ;-) -- Henrique Dante de Almeida hdante@gmail.com From nkoch at demig.de Mon Jul 13 14:32:42 2009 From: nkoch at demig.de (Norbert Koch) Date: Mon Jul 13 14:32:49 2009 Subject: bus device driver Message-ID: <4A5B3F1B.3040207@demig.de> Hello. I just started to write a device driver for a multi-function pci card. This card replaces a number of independant isa hardware devices. This pci card contains memory, i/o and interrupt sources. I want my device driver to serve as a bus driver between the pci driver and the specific device drivers. Do I need more than the following (see below)? Do I have to do any bookkeeping for allocated resources? /*****************************************/ int mypci_probe (device_t dev) { if (pci_get_vendor (dev) == MYVENDOR && pci_get_devid (dev) == MYDEVID) { device_set_desc (dev, "MYPCI bus"); return 0; }; return ENXIO; } static devclass_t mypci_devclass; /* stolen from ISA/PCI brigde */ static device_method_t mypci_methods[] = { /* device */ DEVMETHOD (device_probe, mypci_probe), DEVMETHOD (device_attach, bus_generic_attach), DEVMETHOD (device_detach, bus_generic_detach), /* bus */ DEVMETHOD (bus_print_child, bus_generic_print_child), DEVMETHOD (bus_alloc_resource, bus_generic_alloc_resource), DEVMETHOD (bus_release_resource, bus_generic_release_resource), DEVMETHOD (bus_activate_resource, bus_generic_activate_resource), DEVMETHOD (bus_deactivate_resource, bus_generic_deactivate_resource), DEVMETHOD (bus_setup_intr, bus_generic_setup_intr), DEVMETHOD (bus_teardown_intr, bus_generic_teardown_intr), {0, 0} }; static driver_t mypci_driver = { "mypci", mypci_methods, 0 }; /*****************************************/ Thank you for any help. Norbert Koch From jhb at freebsd.org Mon Jul 13 18:44:43 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 13 18:45:07 2009 Subject: callout(9) and Giant lock In-Reply-To: References: <4A4740B8.8090205@embedded-brains.de> Message-ID: <200907131417.53876.jhb@freebsd.org> On Sunday 28 June 2009 11:57:05 am Robert Watson wrote: > > On Sun, 28 Jun 2009, Sebastian Huber wrote: > > > suppose that a certain time event triggered several callout functions. What > > happens if the first of these callout functions blocks on the Giant lock? > > Does this delay all further callout functions until the Giant lock is > > available for the first callout function? What happens if one of the callout > > function blocks forever? Does this deadlock the system? > > Callouts are marked as MPSAFE or non-MPSAFE when registered. If non-MPSAFE, > we will acquire Giant automatically for the callout, but I believe we'll also > try and sort non-MPSAFE callouts behind MPSAFE ones in execution order to > minimize latency for MPSAFE callouts. Most callouts acquire locks of some > sort, and stalling any callout indefinitely will stall the entire callout > thread indefinitely, which in turn could lead to a variety of odd behaviors > and potentially (although not necessarily) deadlock. FWIW, we do not actually sort the callouts in this manner, so all callouts will be blocked until Giant is acquired. -- John Baldwin From jhb at freebsd.org Mon Jul 13 18:44:43 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 13 18:45:07 2009 Subject: callout(9) and Giant lock In-Reply-To: References: <4A4740B8.8090205@embedded-brains.de> Message-ID: <200907131417.53876.jhb@freebsd.org> On Sunday 28 June 2009 11:57:05 am Robert Watson wrote: > > On Sun, 28 Jun 2009, Sebastian Huber wrote: > > > suppose that a certain time event triggered several callout functions. What > > happens if the first of these callout functions blocks on the Giant lock? > > Does this delay all further callout functions until the Giant lock is > > available for the first callout function? What happens if one of the callout > > function blocks forever? Does this deadlock the system? > > Callouts are marked as MPSAFE or non-MPSAFE when registered. If non-MPSAFE, > we will acquire Giant automatically for the callout, but I believe we'll also > try and sort non-MPSAFE callouts behind MPSAFE ones in execution order to > minimize latency for MPSAFE callouts. Most callouts acquire locks of some > sort, and stalling any callout indefinitely will stall the entire callout > thread indefinitely, which in turn could lead to a variety of odd behaviors > and potentially (although not necessarily) deadlock. FWIW, we do not actually sort the callouts in this manner, so all callouts will be blocked until Giant is acquired. -- John Baldwin From jhb at freebsd.org Mon Jul 13 18:44:45 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 13 18:45:08 2009 Subject: mmap/munmap with zero length In-Reply-To: References: Message-ID: <200907131428.08923.jhb@freebsd.org> On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: > so mmap differs from the POSIX recommendation right. the malloc.conf option > seems more like a workaround/hack. imo it's confusing to have mmap und munmap > deal differently with len=0. being able to succesfully alocate memory which > cannot be removed doesn't seem logical to me. This should fix it: --- //depot/user/jhb/acpipci/vm/vm_mmap.c +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c @@ -229,7 +229,7 @@ fp = NULL; /* make sure mapping fits into numeric range etc */ - if ((ssize_t) uap->len < 0 || + if ((ssize_t) uap->len <= 0 || ((flags & MAP_ANON) && uap->fd != -1)) return (EINVAL); -- John Baldwin From jhb at freebsd.org Mon Jul 13 18:44:46 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 13 18:45:09 2009 Subject: bus device driver In-Reply-To: <4A5B3F1B.3040207@demig.de> References: <4A5B3F1B.3040207@demig.de> Message-ID: <200907131435.30452.jhb@freebsd.org> On Monday 13 July 2009 10:05:15 am Norbert Koch wrote: > Hello. > > I just started to write a device > driver for a multi-function pci card. > This card replaces a number of > independant isa hardware devices. > This pci card contains memory, i/o > and interrupt sources. > I want my device driver to > serve as a bus driver between > the pci driver and the specific > device drivers. > > Do I need more than the following (see below)? > Do I have to do any bookkeeping for allocated resources? How do the child devices receive resources? Do they suballocate regions from BARs in the PCI device or is your device a subtractive bridge that will forward requests for ISA ranges and your devices all use ISA ranges? -- John Baldwin From rwatson at freebsd.org Mon Jul 13 18:49:27 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Mon Jul 13 18:49:34 2009 Subject: callout(9) and Giant lock In-Reply-To: <200907131417.53876.jhb@freebsd.org> References: <4A4740B8.8090205@embedded-brains.de> <200907131417.53876.jhb@freebsd.org> Message-ID: <732D77F4-6D18-4724-A76C-FB38B9DAE0F1@freebsd.org> On 13 Jul 2009, at 19:17, John Baldwin wrote: >> Callouts are marked as MPSAFE or non-MPSAFE when registered. If >> non-MPSAFE, >> we will acquire Giant automatically for the callout, but I believe >> we'll also >> try and sort non-MPSAFE callouts behind MPSAFE ones in execution >> order to >> minimize latency for MPSAFE callouts. Most callouts acquire locks >> of some >> sort, and stalling any callout indefinitely will stall the entire >> callout >> thread indefinitely, which in turn could lead to a variety of odd >> behaviors >> and potentially (although not necessarily) deadlock. > > FWIW, we do not actually sort the callouts in this manner, so all > callouts > will be blocked until Giant is acquired. I must have been remembering a proposed change -- as you say, it's certainly not in kern_timeout.c. However, I'd rather just eliminate support for Giant in callouts in 9.x than try to further facilitate them :-) Robert From jhb at freebsd.org Mon Jul 13 19:26:28 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 13 19:26:35 2009 Subject: callout(9) and Giant lock In-Reply-To: <732D77F4-6D18-4724-A76C-FB38B9DAE0F1@freebsd.org> References: <4A4740B8.8090205@embedded-brains.de> <200907131417.53876.jhb@freebsd.org> <732D77F4-6D18-4724-A76C-FB38B9DAE0F1@freebsd.org> Message-ID: <200907131505.04688.jhb@freebsd.org> On Monday 13 July 2009 2:49:24 pm Robert N. M. Watson wrote: > > On 13 Jul 2009, at 19:17, John Baldwin wrote: > > >> Callouts are marked as MPSAFE or non-MPSAFE when registered. If > >> non-MPSAFE, > >> we will acquire Giant automatically for the callout, but I believe > >> we'll also > >> try and sort non-MPSAFE callouts behind MPSAFE ones in execution > >> order to > >> minimize latency for MPSAFE callouts. Most callouts acquire locks > >> of some > >> sort, and stalling any callout indefinitely will stall the entire > >> callout > >> thread indefinitely, which in turn could lead to a variety of odd > >> behaviors > >> and potentially (although not necessarily) deadlock. > > > > FWIW, we do not actually sort the callouts in this manner, so all > > callouts > > will be blocked until Giant is acquired. > > I must have been remembering a proposed change -- as you say, it's > certainly not in kern_timeout.c. However, I'd rather just eliminate > support for Giant in callouts in 9.x than try to further facilitate > them :-) Agreed. :) -- John Baldwin From tijl at ulyssis.org Mon Jul 13 20:05:47 2009 From: tijl at ulyssis.org (Tijl Coosemans) Date: Mon Jul 13 20:05:54 2009 Subject: mmap/munmap with zero length In-Reply-To: <200907131428.08923.jhb@freebsd.org> References: <200907131428.08923.jhb@freebsd.org> Message-ID: <200907132133.52217.tijl@ulyssis.org> On Monday 13 July 2009 20:28:08 John Baldwin wrote: > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: >> so mmap differs from the POSIX recommendation right. the malloc.conf >> option seems more like a workaround/hack. imo it's confusing to have >> mmap und munmap deal differently with len=0. being able to >> succesfully alocate memory which cannot be removed doesn't seem >> logical to me. > > This should fix it: > > --- //depot/user/jhb/acpipci/vm/vm_mmap.c > +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c > @@ -229,7 +229,7 @@ > > fp = NULL; > /* make sure mapping fits into numeric range etc */ > - if ((ssize_t) uap->len < 0 || > + if ((ssize_t) uap->len <= 0 || > ((flags & MAP_ANON) && uap->fd != -1)) > return (EINVAL); Why not "uap->len == 0"? Sizes of 2GiB and more (32bit) shouldn't cause an error. From jhb at freebsd.org Mon Jul 13 20:40:46 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 13 20:40:55 2009 Subject: mmap/munmap with zero length In-Reply-To: <200907132133.52217.tijl@ulyssis.org> References: <200907131428.08923.jhb@freebsd.org> <200907132133.52217.tijl@ulyssis.org> Message-ID: <200907131639.10346.jhb@freebsd.org> On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote: > On Monday 13 July 2009 20:28:08 John Baldwin wrote: > > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: > >> so mmap differs from the POSIX recommendation right. the malloc.conf > >> option seems more like a workaround/hack. imo it's confusing to have > >> mmap und munmap deal differently with len=0. being able to > >> succesfully alocate memory which cannot be removed doesn't seem > >> logical to me. > > > > This should fix it: > > > > --- //depot/user/jhb/acpipci/vm/vm_mmap.c > > +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c > > @@ -229,7 +229,7 @@ > > > > fp = NULL; > > /* make sure mapping fits into numeric range etc */ > > - if ((ssize_t) uap->len < 0 || > > + if ((ssize_t) uap->len <= 0 || > > ((flags & MAP_ANON) && uap->fd != -1)) > > return (EINVAL); > > Why not "uap->len == 0"? Sizes of 2GiB and more (32bit) shouldn't cause > an error. I don't actually disagree and know of locally modified versions of FreeBSD that remove this check for precisely that reason. -- John Baldwin From keramida at freebsd.org Tue Jul 14 04:37:21 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Tue Jul 14 04:37:27 2009 Subject: can we afford an extra column in iostat? Message-ID: <87d483q4en.fsf@kobe.laptop> While converting my laptop's main disk to zfs, I noticed iostat output like this (bits copied from here and there): | keramida@kobe:/home/keramida$ iostat -w3 ad0 da0 | tty ad0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id | 5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89 | 0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15 | 012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4 | 050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20 | 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16 | 33835534 7.61 211 1.57 7.31 295 2.11 36 0 55 1 9 | 38636874 3.10 186 0.56 6.63 309 2.00 37 0 56 0 7 | 24239726 2.54 196 0.49 6.13 336 2.01 36 0 56 0 8 | 17136654 0.57 192 0.11 7.97 305 2.37 34 0 56 0 9 | 23439020 0.76 195 0.15 7.02 333 2.28 32 0 57 1 11 | 43733189 2.52 192 0.47 6.99 269 1.84 37 0 57 1 5 | 36232178 5.48 193 1.03 6.78 268 1.77 38 0 54 0 8 | 43226266 34.19 228 7.61 6.94 253 1.72 32 0 49 1 19 The default output of iostat, when no disks are specified is a bit wider than this, reaching column 75 here: 1 2 3 4 5 6 7 12345678901234567890123456789012345678901234567890123456789012345678901234567890 --------------------------------------------------------------------------- tty ad0 md0 da0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 2315 34.97 58 1.99 6.46 0 0.00 47.41 8 0.37 4 0 8 0 88 But there's still a bit of space before column 80, so can we afford an extra space between tin/tout to make the output look more like this? | $ ./iostat -w2 | tty ad0 md0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id | 7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87 | 0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9 | 0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9 | 0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17 | ^C The patch that changes this is quite small: %%% diff -r 0f182a7399e8 usr.sbin/iostat/iostat.c --- a/usr.sbin/iostat/iostat.c Sun Jul 12 09:34:48 2009 +0300 +++ b/usr.sbin/iostat/iostat.c Tue Jul 14 07:20:41 2009 +0300 @@ -586,7 +586,7 @@ } if (xflag == 0 && Tflag > 0) - printf("%4.0Lf%5.0Lf", cur.tk_nin / etime, + printf("%4.0Lf %5.0Lf", cur.tk_nin / etime, cur.tk_nout / etime); devstats(hflag, etime, havelast); @@ -696,7 +696,7 @@ (void)printf("\n"); if (Tflag > 0) - (void)printf(" tin tout"); + (void)printf(" tin tout"); for (i=0, printed = 0;(i < num_devices) && (printed < maxshowdevs);i++){ if ((dev_select[i].selected != 0) @@ -754,7 +754,7 @@ "device r/i w/i kr/i kw/i wait svc_t %%b " ); if (Tflag > 0) - printf("tin tout "); + printf("tin tout "); if (Cflag > 0) printf("us ni sy in id "); printf("\n"); @@ -895,7 +895,7 @@ */ printf("%52s",""); if (Tflag > 0) - printf("%4.0Lf%5.0Lf", cur.tk_nin / etime, + printf("%4.0Lf %5.0Lf", cur.tk_nin / etime, cur.tk_nout / etime); if (Cflag > 0) cpustats(); %%% From nkoch at demig.de Tue Jul 14 07:09:09 2009 From: nkoch at demig.de (Norbert Koch) Date: Tue Jul 14 07:09:17 2009 Subject: bus device driver In-Reply-To: <200907131435.30452.jhb@freebsd.org> References: <4A5B3F1B.3040207@demig.de> <200907131435.30452.jhb@freebsd.org> Message-ID: <4A5C2EF8.3080208@demig.de> John Baldwin schrieb: > On Monday 13 July 2009 10:05:15 am Norbert Koch wrote: > >> Hello. >> >> I just started to write a device >> driver for a multi-function pci card. >> This card replaces a number of >> independant isa hardware devices. >> This pci card contains memory, i/o >> and interrupt sources. >> I want my device driver to >> serve as a bus driver between >> the pci driver and the specific >> device drivers. >> >> Do I need more than the following (see below)? >> Do I have to do any bookkeeping for allocated resources? >> > > How do the child devices receive resources? Do they suballocate regions from > BARs in the PCI device or is your device a subtractive bridge that will > forward requests for ISA ranges and your devices all use ISA ranges? > > I am not quite sure that I understand what you mean. What is the difference? My old device drivers were isa based. We had all our resources in the 15-16M isa hole. So I want to change them to just allocate resources from the pci bus through the bus device driver. I thought it would be sufficient to just forward *_alloc_resource calls directly to the pci driver. Clearly, my drivers will have to know that they are just forwarded through to pci and have to know what sub-resources to allocate. -- Dipl.-Ing. Norbert Koch Entwicklung Prozessregler ***************************************** * demig Prozessautomatisierung GmbH * * * * Anschrift: Haardtstrasse 40 * * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * * Geschaeftsfuehrer: Joachim Herbst, * * Winfried Held * * Telefon: +49 271 772020 * * Telefax: +49 271 74704 * * E-Mail: info@demig.de * * http://www.demig.de * ***************************************** From jhb at freebsd.org Tue Jul 14 14:08:54 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jul 14 14:09:02 2009 Subject: bus device driver In-Reply-To: <4A5C2EF8.3080208@demig.de> References: <4A5B3F1B.3040207@demig.de> <200907131435.30452.jhb@freebsd.org> <4A5C2EF8.3080208@demig.de> Message-ID: <200907140849.51702.jhb@freebsd.org> On Tuesday 14 July 2009 3:08:40 am Norbert Koch wrote: > > John Baldwin schrieb: > > On Monday 13 July 2009 10:05:15 am Norbert Koch wrote: > > > >> Hello. > >> > >> I just started to write a device > >> driver for a multi-function pci card. > >> This card replaces a number of > >> independant isa hardware devices. > >> This pci card contains memory, i/o > >> and interrupt sources. > >> I want my device driver to > >> serve as a bus driver between > >> the pci driver and the specific > >> device drivers. > >> > >> Do I need more than the following (see below)? > >> Do I have to do any bookkeeping for allocated resources? > >> > > > > How do the child devices receive resources? Do they suballocate regions from > > BARs in the PCI device or is your device a subtractive bridge that will > > forward requests for ISA ranges and your devices all use ISA ranges? > > > > > I am not quite sure that I understand what you mean. What is the difference? > My old device drivers were isa based. We had all our resources in the > 15-16M isa hole. > So I want to change them to just allocate resources from the pci bus > through the bus device driver. > I thought it would be sufficient to just forward *_alloc_resource calls > directly to the pci driver. > Clearly, my drivers will have to know that they are just forwarded > through to pci > and have to know what sub-resources to allocate. From a hardware perspective, how do your devices know which addresses to decode? Do they consume subranges of BARs or are they assigned fixed addresses somehow? Do they have programmable decoders of some sort themselves? If you wish to have the PCI bus assign you resources then that implies that your PCI device has a BAR and that you want to request resources for that BAR and then hand out subranges of that to your children. If that is the case, then you will need to allocate the resources for the BAR for the PCI device from the PCI bus. Then your bus driver for the PCI device will need to suballoc from that BAR to your children devices. -- John Baldwin From nkoch at demig.de Tue Jul 14 15:31:32 2009 From: nkoch at demig.de (Norbert Koch) Date: Tue Jul 14 15:31:38 2009 Subject: bus device driver In-Reply-To: <200907140849.51702.jhb@freebsd.org> References: <4A5B3F1B.3040207@demig.de> <200907131435.30452.jhb@freebsd.org> <4A5C2EF8.3080208@demig.de> <200907140849.51702.jhb@freebsd.org> Message-ID: <4A5CA4AA.6050307@demig.de> > From a hardware perspective, how do your devices know which addresses to > decode? Do they consume subranges of BARs or are they assigned fixed > addresses somehow? Do they have programmable decoders of some sort > themselves? If you wish to have the PCI bus assign you resources then that > implies that your PCI device has a BAR and that you want to request resources > for that BAR and then hand out subranges of that to your children. If that > is the case, then you will need to allocate the resources for the BAR for the > PCI device from the PCI bus. Then your bus driver for the PCI device will > need to suballoc from that BAR to your children devices. > > My device decodes one ram address range (16MB) and gives me one interrupt line. As my sub-devices operate on partial address areas my idea was to let them all call bus_alloc_resource() with the same rid parameter (= BAR selector) and different offsets. So the bookkeeping should be done by the pci driver, right? From alc at cs.rice.edu Tue Jul 14 16:32:45 2009 From: alc at cs.rice.edu (Alan Cox) Date: Tue Jul 14 16:32:53 2009 Subject: mmap/munmap with zero length In-Reply-To: <200907131639.10346.jhb@freebsd.org> References: <200907131428.08923.jhb@freebsd.org> <200907132133.52217.tijl@ulyssis.org> <200907131639.10346.jhb@freebsd.org> Message-ID: <4A5CB324.80708@cs.rice.edu> John Baldwin wrote: > On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote: > >> On Monday 13 July 2009 20:28:08 John Baldwin wrote: >> >>> On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: >>> >>>> so mmap differs from the POSIX recommendation right. the malloc.conf >>>> option seems more like a workaround/hack. imo it's confusing to have >>>> mmap und munmap deal differently with len=0. being able to >>>> succesfully alocate memory which cannot be removed doesn't seem >>>> logical to me. >>>> >>> This should fix it: >>> >>> --- //depot/user/jhb/acpipci/vm/vm_mmap.c >>> +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c >>> @@ -229,7 +229,7 @@ >>> >>> fp = NULL; >>> /* make sure mapping fits into numeric range etc */ >>> - if ((ssize_t) uap->len < 0 || >>> + if ((ssize_t) uap->len <= 0 || >>> ((flags & MAP_ANON) && uap->fd != -1)) >>> return (EINVAL); >>> >> Why not "uap->len == 0"? Sizes of 2GiB and more (32bit) shouldn't cause >> an error. >> > > I don't actually disagree and know of locally modified versions of FreeBSD > that remove this check for precisely that reason. > > I have no objections to "uap->len == 0" (without the cast). Alan From jhb at freebsd.org Tue Jul 14 17:39:18 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jul 14 17:39:24 2009 Subject: bus device driver In-Reply-To: <4A5CA4AA.6050307@demig.de> References: <4A5B3F1B.3040207@demig.de> <200907140849.51702.jhb@freebsd.org> <4A5CA4AA.6050307@demig.de> Message-ID: <200907141151.29971.jhb@freebsd.org> On Tuesday 14 July 2009 11:30:50 am Norbert Koch wrote: > > > From a hardware perspective, how do your devices know which addresses to > > decode? Do they consume subranges of BARs or are they assigned fixed > > addresses somehow? Do they have programmable decoders of some sort > > themselves? If you wish to have the PCI bus assign you resources then that > > implies that your PCI device has a BAR and that you want to request resources > > for that BAR and then hand out subranges of that to your children. If that > > is the case, then you will need to allocate the resources for the BAR for the > > PCI device from the PCI bus. Then your bus driver for the PCI device will > > need to suballoc from that BAR to your children devices. > > > > > My device decodes one ram address range (16MB) and gives me > one interrupt line. > As my sub-devices operate on partial address areas my idea was to > let them all call bus_alloc_resource() with the same rid parameter (= > BAR selector) > and different offsets. So the bookkeeping should be done by the pci > driver, right? No. First of all, the PCI bus driver will only allocate resources for direct children. It simply passes requests up the tree for grandchildren (this is how ISA devices behind a PCI-ISA bridge request resources). In this case, you will want to allocate resources for your BAR and your interrupt using bus_alloc_resource() during your attach routine. You can then either share the resources directly with your children by returning your resource values in your own bus_alloc_resource() method (see ppc(4) for an example of this) or subdivide your resource to make new resources (the easiest way to do this is probably to create a rman from your resource and then use rman_reserve_resource() to sub-allocate chunks of that to your children). For the interrupt resource you can just return your own resource pointer directly in your bus_alloc_resource() routine. -- John Baldwin From brian at FreeBSD.org Tue Jul 14 22:23:24 2009 From: brian at FreeBSD.org (Brian Somers) Date: Tue Jul 14 22:23:30 2009 Subject: can we afford an extra column in iostat? In-Reply-To: <87d483q4en.fsf@kobe.laptop> References: <87d483q4en.fsf@kobe.laptop> Message-ID: <20090714145515.43e309ca@Awfulhak.org> On Tue, 14 Jul 2009 07:23:12 +0300, Giorgos Keramidas wrote: > While converting my laptop's main disk to zfs, I noticed iostat output > like this (bits copied from here and there): > > | keramida@kobe:/home/keramida$ iostat -w3 ad0 da0 > | tty ad0 da0 cpu > | tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > | 5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89 > | 0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15 > | 012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4 > | 050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20 > | 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16 >[.....] > | $ ./iostat -w2 > | tty ad0 md0 da0 cpu > | tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > | 7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87 > | 0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9 > | 0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9 > | 0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17 > | ^C > > The patch that changes this is quite small: This should be fixed. Ironically, the only people that usually have problems with fixes like this are people that have seen the fields merge and have adjusted some script to understand column widths! -- Brian Somers Don't _EVER_ lose your sense of humour ! From keramida at freebsd.org Tue Jul 14 23:28:23 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Tue Jul 14 23:28:32 2009 Subject: can we afford an extra column in iostat? In-Reply-To: <20090714145515.43e309ca@Awfulhak.org> (Brian Somers's message of "Tue, 14 Jul 2009 14:55:15 -0700") References: <87d483q4en.fsf@kobe.laptop> <20090714145515.43e309ca@Awfulhak.org> Message-ID: <87vdluetfe.fsf@kobe.laptop> On Tue, 14 Jul 2009 14:55:15 -0700, Brian Somers wrote: > On Tue, 14 Jul 2009 07:23:12 +0300, Giorgos Keramidas wrote: >> While converting my laptop's main disk to zfs, I noticed iostat output >> like this (bits copied from here and there): >> >> | keramida@kobe:/home/keramida$ iostat -w3 ad0 da0 >> | tty ad0 da0 cpu >> | tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >> | 5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89 >> | 0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15 >> | 012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4 >> | 050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20 >> | 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16 >>[.....] >> | $ ./iostat -w2 >> | tty ad0 md0 da0 cpu >> | tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >> | 7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87 >> | 0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9 >> | 0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9 >> | 0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17 >> | ^C >> >> The patch that changes this is quite small: > > This should be fixed. Ironically, the only people that usually > have problems with fixes like this are people that have seen > the fields merge and have adjusted some script to understand > column widths! Yes, that's a bit unfortunate. I'm ok with keeping this in 8.X only for this reason alone, but I would prefer if it was eventually MFCd. I'll ask re@ if they are ok with committing this now in head. Thanks :) From nkoch at demig.de Wed Jul 15 07:19:26 2009 From: nkoch at demig.de (Norbert Koch) Date: Wed Jul 15 07:19:33 2009 Subject: bus device driver In-Reply-To: <200907141151.29971.jhb@freebsd.org> References: <4A5B3F1B.3040207@demig.de> <200907140849.51702.jhb@freebsd.org> <4A5CA4AA.6050307@demig.de> <200907141151.29971.jhb@freebsd.org> Message-ID: <4A5D82D1.8030608@demig.de> > No. First of all, the PCI bus driver will only allocate resources for direct > children. It simply passes requests up the tree for grandchildren (this is > how ISA devices behind a PCI-ISA bridge request resources). In this case, > you will want to allocate resources for your BAR and your interrupt using > bus_alloc_resource() during your attach routine. You can then either share > the resources directly with your children by returning your resource values > in your own bus_alloc_resource() method (see ppc(4) for an example of this) > or subdivide your resource to make new resources (the easiest way to do this > is probably to create a rman from your resource and then use > rman_reserve_resource() to sub-allocate chunks of that to your children). > For the interrupt resource you can just return your own resource pointer > directly in your bus_alloc_resource() routine. > > Ok, that makes things a bit clearer. Thank you for your help! From sos at deepcore.dk Wed Jul 15 14:48:55 2009 From: sos at deepcore.dk (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Wed Jul 15 14:58:55 2009 Subject: ATA driver update for 7.2RELEASE available In-Reply-To: <4A5DA250.9000902@ksu.ru> References: <8EB69F68-8ED2-469C-B83E-2555A72630B4@deepcore.dk> <4A5DA250.9000902@ksu.ru> Message-ID: On 15Jul, 2009, at 11:33 , Marat N.Afanasyev wrote: > S?ren Schmidt wrote: >> Over the past months I've gotten huge amounts of requests for ATA >> related things, so I've whipped up what I use here for FreeBSD 7.2- >> Release. >> This is a total replacement of the ATA driver, modulerized as in - >> current, but based on my WIP not from what might have happend to - >> current since I gave up maintainership. >> There is a number of new chipsets supported in here that I dont >> think is in any of the official sources (havn't checked in quite >> some time though), mostly newish ATI, nVidia and Marvell chips >> (yeah those buggers with both ATA & SATA ports). >> You can find and install.sh script and a tarball of the needed >> files at: >> http://www.deepcore.dk/pub/ATA >> Put both in /usr/src and run install.sh. >> As I dont subscribe to any of the mailing lists nor does my >> FreeBSD.org mail address seem to work anymore, you will need to >> reply to me directly if needed. >> As always - Enjoy! >> -S?ren > > i think i'm dumb, but can you tell me how can atapicam be enabled > with this implementation of ata? i couldn't still find a way :( You could just grap atapi-cam.c from stock 7.2 and use that I guess (as a module or compiled in), newer used it though... -S?ren -- From oliver.pntr at gmail.com Thu Jul 16 17:35:58 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Thu Jul 16 17:36:15 2009 Subject: ZFS: freebsd-current vs osol2009.06 Message-ID: <6101e8c40907161011o57b3ae0bi8af2e6ebd9dc1364@mail.gmail.com> http://209.85.129.132/translate_c?hl=en&u=http://suckit.blog.hu/2009/07/16/zfs_sebesseg_freebsd_vs_opensolaris&rurl=translate.google.com&usg=ALkJrhhn2z8lEDw1hZEUEqAiCZ330Gw41w From des at des.no Fri Jul 17 10:50:32 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Jul 17 10:50:39 2009 Subject: Help on relicensing derived code In-Reply-To: (Henrique Almeida's message of "Sun, 12 Jul 2009 16:20:18 -0300") References: Message-ID: <86iqhrh9c9.fsf@ds4.des.no> Henrique Almeida writes: > I need to write an "errno.h" with constant values used by the FreeBSD > kernel. My project uses exclusively the 2 clause BSD license. I > expected to copy those values from FreeBSD errno.h. However, FreeBSD > errno.h has 3 clauses. I'm a total newbie in licensing procedures so, > it's not clear what to do. In the US at least, you can safely ignore the license and copy the macro definitions themselves. There is plenty of legal precedent (including but not limited to SCO vs. IBM) to back that up. I'm unsure about the comments, though. DES -- Dag-Erling Sm?rgrav - des@des.no From Andre.Albsmeier at siemens.com Fri Jul 17 19:32:40 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Fri Jul 17 19:32:47 2009 Subject: Reading acpi memory from a driver attached to hostb Message-ID: <20090717190450.GA4697@curry.mchp.siemens.de> [CC'ing this to Rui Paulo since he tried to help me a while ago] I have written a driver that is a child of hostb (similar to agp) for RELENG_7. However, on some chipsets (e.g. i975) it has to read some memory locations (not pci configuration space) which were registered by acpi as system resources. Since my driver is a child of hostb0, I have no idea of how to access this memory area. Here is a devinfo -r to make things clear: nexus0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f ... 0x800-0x87f I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xf0000000-0xf3ffffff 0xfec00000-0xfec00fff 0xfed13000-0xfed19fff <--- the memory needed 0xfed1c000-0xfed1ffff .... 0xfed20000-0xfed3ffff 0xfff00000-0xffffffff cpu0 coretemp0 acpi_throttle0 ACPI I/O ports: 0x810-0x813 cpufreq0 cpu1 coretemp1 pcib0 pci0 I/O ports: 0x170-0x177 0x376 hostb0 I/O memory addresses: 0xe4000000-0xe7ffffff MYDRIVER0 <--- my driver agp0 pcib1 pci7 vgapci0 Interrupt request lines: 16 I had the same problem under RELENG_6 six month ago which could be solved by a bus_set_resource() but since the driver now attaches to hostb, this is not possible anymore. Earlier, I was given the hint to attach as a child of acpi (see the old mail attached below) but in this case I didn't have access to the hostb registers which I need as well. The only thing I see is: Attach two drivers -- one as child of acpi and another as child of hostb and let them communicate somehow (no idea how to do this). I have also done crazy things like searching for acpi0 and trying to bus_alloc_resource() the memory I am interested in but this also failed. Or is it possible to free(!) somehow the address space from acpi0 and pass it to hostb0 so I can bus_alloc_resource() it? Thanks a lot for all ideas, -Andre ------------------------------------------------------------------ > Hello all, > > I am writing a driver which needs to access memory at a > specific location. The location depends on what the BIOS > has configured into the host bridge. For example, my > current machine uses an Intel 975X chipset and the memory > location I am interested in has been set to 0xFED14000 and > is 16KB in size (this is MCHBAR of the 975X memory hub). You probably just need to do something like: rid = PCI_BAR(number); res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); And then, bus_read_4(res, offset from specified PCI BAR); > > > I have no idea how to access this space from my driver. > I have played around with bus_alloc_resource() but this > only gives me back NULL. > > However, a devinfo -r gives me: > > nexus0 > npx0 > acpi0 > Interrupt request lines: > 9 > I/O ports: > 0x10-0x1f > ... > 0x800-0x87f > I/O memory addresses: > 0x0-0x9ffff > 0xc0000-0xdffff > 0xe0000-0xfffff > 0x100000-0x7fffffff > 0xf0000000-0xf3ffffff > 0xfec00000-0xfec00fff > 0xfed13000-0xfed19fff <--- > 0xfed1c000-0xfed1ffff > 0xfed20000-0xfed3ffff > 0xfed50000-0xfed8ffff > 0xfee00000-0xfee00fff > 0xffb00000-0xffbfffff > 0xfff00000-0xffffffff > cpu0 > ... > > The line marked with <--- shows the range which includes > the location I am interested in. It is probably assigned > to the acpi0 device. > > How do I proceed from this? Do I have to hack around in > the ACPI-Code? I don't hope so ;-) You'll probably need to create a fake ACPI child driver to access it. Create your identify routine with something like: static void mydriver_identify(driver_t *driver, device_t parent) { if (device_find_child(parent, "mydriver", -1) == NULL && mydriver_match(parent)) device_add_child(parent, "mydriver", -1); } mydriver_match() should check if you were given the acpi0 device. Regards, -- Rui Paulo From julian at elischer.org Fri Jul 17 19:53:55 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jul 17 19:54:01 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <20090717190450.GA4697@curry.mchp.siemens.de> References: <20090717190450.GA4697@curry.mchp.siemens.de> Message-ID: <4A60D6D1.3050703@elischer.org> Andre Albsmeier wrote: > [CC'ing this to Rui Paulo since he tried to help me a while ago] > > I have written a driver that is a child of hostb (similar to agp) for > RELENG_7. However, on some chipsets (e.g. i975) it has to read some > memory locations (not pci configuration space) which were registered > by acpi as system resources. > > Since my driver is a child of hostb0, I have no idea of how to access > this memory area. Here is a devinfo -r to make things clear: > > nexus0 > acpi0 > Interrupt request lines: > 9 > I/O ports: > 0x10-0x1f > 0x22-0x3f > ... > 0x800-0x87f > I/O memory addresses: > 0xc0000-0xdffff > 0xe0000-0xfffff > 0xf0000000-0xf3ffffff > 0xfec00000-0xfec00fff > 0xfed13000-0xfed19fff <--- the memory needed > 0xfed1c000-0xfed1ffff > .... > 0xfed20000-0xfed3ffff > 0xfff00000-0xffffffff > cpu0 > coretemp0 > acpi_throttle0 > ACPI I/O ports: > 0x810-0x813 > cpufreq0 > cpu1 > coretemp1 > pcib0 > pci0 > I/O ports: > 0x170-0x177 > 0x376 > hostb0 > I/O memory addresses: > 0xe4000000-0xe7ffffff > MYDRIVER0 <--- my driver > agp0 > pcib1 > pci7 > vgapci0 > Interrupt request lines: > 16 > > I had the same problem under RELENG_6 six month ago which could be > solved by a bus_set_resource() but since the driver now attaches to > hostb, this is not possible anymore. > > Earlier, I was given the hint to attach as a child of acpi (see the > old mail attached below) but in this case I didn't have access to the > hostb registers which I need as well. > > The only thing I see is: Attach two drivers -- one as child of acpi > and another as child of hostb and let them communicate somehow (no > idea how to do this). > > I have also done crazy things like searching for acpi0 and trying > to bus_alloc_resource() the memory I am interested in but this also > failed. > > Or is it possible to free(!) somehow the address space from acpi0 > and pass it to hostb0 so I can bus_alloc_resource() it? > > Thanks a lot for all ideas, > > -Andre > You can probably make two drivers in one which cooperate to allow access to both sets of resources. > From Andre.Albsmeier at siemens.com Sat Jul 18 09:03:52 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Sat Jul 18 09:04:01 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <4A60D6D1.3050703@elischer.org> References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> Message-ID: <20090718081011.GA6920@curry.mchp.siemens.de> On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > Andre Albsmeier wrote: > > [CC'ing this to Rui Paulo since he tried to help me a while ago] > > > > Since my driver is a child of hostb0, I have no idea of how to access > > acpi0's memory area. Here is a devinfo -r to make things clear: > > > ... > > > > Earlier, I was given the hint to attach as a child of acpi (see the > > old mail attached below) but in this case I didn't have access to the > > hostb registers which I need as well. > > > > The only thing I see is: Attach two drivers -- one as child of acpi > > and another as child of hostb and let them communicate somehow (no > > idea how to do this). > > > > I have also done crazy things like searching for acpi0 and trying > > to bus_alloc_resource() the memory I am interested in but this also > > failed. > > > > Or is it possible to free(!) somehow the address space from acpi0 > > and pass it to hostb0 so I can bus_alloc_resource() it? > > > > You can probably make two drivers in one which cooperate to > allow access to both sets of resources. Hmm, that's what I meant by: Attach two drivers -- one as child of acpi and another as child of hostb... And that's similar to Rui Paulo's suggestion a while ago: > You'll probably need to create a fake ACPI child driver to access it. > > Create your identify routine with something like: > > static void mydriver_identify(driver_t *driver, device_t parent) > { > if (device_find_child(parent, "mydriver", -1) == NULL && > mydriver_match(parent)) > device_add_child(parent, "mydriver", -1); > } > > mydriver_match() should check if you were given the acpi0 device. But in order to attach to acpi0, I need to say DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, NULL ); instead of DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, NULL ); This way I could attach to acpi but not to hostb anymore.... I have searched the net for solutions, I have read newbus-draft.txt and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all of these my driver is working on other mainboards where it doesn't have to access foreign memory) but didn't find anything. Thanks, -Andre From rpaulo at freebsd.org Sat Jul 18 09:47:48 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Sat Jul 18 09:47:54 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <20090718081011.GA6920@curry.mchp.siemens.de> References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> <20090718081011.GA6920@curry.mchp.siemens.de> Message-ID: On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: >> Andre Albsmeier wrote: >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] >>> >>> Since my driver is a child of hostb0, I have no idea of how to >>> access >>> acpi0's memory area. Here is a devinfo -r to make things clear: >>> >> ... >>> >>> Earlier, I was given the hint to attach as a child of acpi (see the >>> old mail attached below) but in this case I didn't have access to >>> the >>> hostb registers which I need as well. >>> >>> The only thing I see is: Attach two drivers -- one as child of acpi >>> and another as child of hostb and let them communicate somehow (no >>> idea how to do this). >>> >>> I have also done crazy things like searching for acpi0 and trying >>> to bus_alloc_resource() the memory I am interested in but this also >>> failed. >>> >>> Or is it possible to free(!) somehow the address space from acpi0 >>> and pass it to hostb0 so I can bus_alloc_resource() it? >>> >> >> You can probably make two drivers in one which cooperate to >> allow access to both sets of resources. > > Hmm, that's what I meant by: Attach two drivers -- one as child of > acpi > and another as child of hostb... > > And that's similar to Rui Paulo's suggestion a while ago: > >> You'll probably need to create a fake ACPI child driver to access it. >> >> Create your identify routine with something like: >> >> static void mydriver_identify(driver_t *driver, device_t parent) >> { >> if (device_find_child(parent, "mydriver", -1) == NULL && >> mydriver_match(parent)) >> device_add_child(parent, "mydriver", -1); >> } >> >> mydriver_match() should check if you were given the acpi0 device. > > But in order to attach to acpi0, I need to say > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > NULL ); > > instead of > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > NULL ); > > This way I could attach to acpi but not to hostb anymore.... > > I have searched the net for solutions, I have read newbus-draft.txt > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > of these my driver is working on other mainboards where it doesn't > have to access foreign memory) but didn't find anything. I'm out of ideas. John, do you know if this is a newbus limitation or if it can be worked around ? -- Rui Paulo From Andre.Albsmeier at siemens.com Sat Jul 18 13:39:43 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Sat Jul 18 13:39:49 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> <20090718081011.GA6920@curry.mchp.siemens.de> Message-ID: <20090718133938.GA7802@curry.mchp.siemens.de> On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > >> Andre Albsmeier wrote: > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > >>> > >>> Since my driver is a child of hostb0, I have no idea of how to > >>> access > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > >>> > >> ... > >>> > >>> Earlier, I was given the hint to attach as a child of acpi (see the > >>> old mail attached below) but in this case I didn't have access to > >>> the > >>> hostb registers which I need as well. > >>> > >>> The only thing I see is: Attach two drivers -- one as child of acpi > >>> and another as child of hostb and let them communicate somehow (no > >>> idea how to do this). > >>> > >>> I have also done crazy things like searching for acpi0 and trying > >>> to bus_alloc_resource() the memory I am interested in but this also > >>> failed. > >>> > >>> Or is it possible to free(!) somehow the address space from acpi0 > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > >>> > >> > >> You can probably make two drivers in one which cooperate to > >> allow access to both sets of resources. > > > > Hmm, that's what I meant by: Attach two drivers -- one as child of > > acpi > > and another as child of hostb... > > > > And that's similar to Rui Paulo's suggestion a while ago: > > > >> You'll probably need to create a fake ACPI child driver to access it. > >> > >> Create your identify routine with something like: > >> > >> static void mydriver_identify(driver_t *driver, device_t parent) > >> { > >> if (device_find_child(parent, "mydriver", -1) == NULL && > >> mydriver_match(parent)) > >> device_add_child(parent, "mydriver", -1); > >> } > >> > >> mydriver_match() should check if you were given the acpi0 device. > > > > But in order to attach to acpi0, I need to say > > > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > > NULL ); > > > > instead of > > > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > > NULL ); > > > > This way I could attach to acpi but not to hostb anymore.... > > > > I have searched the net for solutions, I have read newbus-draft.txt > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > > of these my driver is working on other mainboards where it doesn't > > have to access foreign memory) but didn't find anything. > > I'm out of ideas. > John, do you know if this is a newbus limitation or if it can be > worked around ? I assume it is possible somehow, I am just too stupid (it is the first driver I wrote). John, for easy reference, here is my initial message: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html Please remember all, that I need the access to the acpi0 memory location only for a few reads during probing/attaching, not later. I have also read somewhere that, when resources are allocated, the system "walks up" the device tree until it finds the resource. Since my driver is below hostb0 and hostb0 is below acpi0 I thought it should work but it doesn't.. Thanks again, -Andre From julian at elischer.org Sat Jul 18 14:06:52 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Jul 18 14:06:58 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <20090718081011.GA6920@curry.mchp.siemens.de> References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> <20090718081011.GA6920@curry.mchp.siemens.de> Message-ID: <4A61D6FB.2090904@elischer.org> Andre Albsmeier wrote: > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: >> Andre Albsmeier wrote: >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] >>> >>> Since my driver is a child of hostb0, I have no idea of how to access >>> acpi0's memory area. Here is a devinfo -r to make things clear: >>> >> ... >>> Earlier, I was given the hint to attach as a child of acpi (see the >>> old mail attached below) but in this case I didn't have access to the >>> hostb registers which I need as well. >>> >>> The only thing I see is: Attach two drivers -- one as child of acpi >>> and another as child of hostb and let them communicate somehow (no >>> idea how to do this). >>> >>> I have also done crazy things like searching for acpi0 and trying >>> to bus_alloc_resource() the memory I am interested in but this also >>> failed. >>> >>> Or is it possible to free(!) somehow the address space from acpi0 >>> and pass it to hostb0 so I can bus_alloc_resource() it? >>> >> You can probably make two drivers in one which cooperate to >> allow access to both sets of resources. > > Hmm, that's what I meant by: Attach two drivers -- one as child of acpi > and another as child of hostb... > > And that's similar to Rui Paulo's suggestion a while ago: > >> You'll probably need to create a fake ACPI child driver to access it. >> >> Create your identify routine with something like: >> >> static void mydriver_identify(driver_t *driver, device_t parent) >> { >> if (device_find_child(parent, "mydriver", -1) == NULL && >> mydriver_match(parent)) >> device_add_child(parent, "mydriver", -1); >> } >> >> mydriver_match() should check if you were given the acpi0 device. > > But in order to attach to acpi0, I need to say > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, NULL ); > > instead of > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, NULL ); try both with different devclass and other args. > > This way I could attach to acpi but not to hostb anymore.... > > I have searched the net for solutions, I have read newbus-draft.txt > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > of these my driver is working on other mainboards where it doesn't > have to access foreign memory) but didn't find anything. > > Thanks, > > -Andre From killing at multiplay.co.uk Sun Jul 19 13:10:57 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sun Jul 19 13:11:04 2009 Subject: i386_set_ldt on FreeBSD 7.x amd64 Message-ID: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> I'm trying to convert some audio streams and the only app which seems to be capable of this mplayer with the w32codecs Unfortunately the machine is 7.1 amd64. I've compiled the binaries up on an old i386 box but when running said bins on the amd64 box it errors with: Opening audio decoder: [dmo] Win32/DMO decoders install_fs: Invalid argument Couldn't install fs segment, expect segfault Looking at the code the call to i386_set_ldt is failing is there any know workaround? Looking on Google there is a thread: i386_set_ldt and wine on AMD64 which mentions some patches by kib but no mention if this ever worked. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=233316+0+archive/2008/freebsd-amd64/20081214.freebsd-amd64 The latest version I can find is: http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch Anyone info appreciated. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From kostikbel at gmail.com Sun Jul 19 14:04:34 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Jul 19 14:04:41 2009 Subject: i386_set_ldt on FreeBSD 7.x amd64 In-Reply-To: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> Message-ID: <20090719134850.GX55190@deviant.kiev.zoral.com.ua> On Sun, Jul 19, 2009 at 02:00:00PM +0100, Steven Hartland wrote: > I'm trying to convert some audio streams and the only app > which seems to be capable of this mplayer with the w32codecs > > Unfortunately the machine is 7.1 amd64. I've compiled the > binaries up on an old i386 box but when running said bins > on the amd64 box it errors with: > > Opening audio decoder: [dmo] Win32/DMO decoders > install_fs: Invalid argument > Couldn't install fs segment, expect segfault > > Looking at the code the call to i386_set_ldt is failing > is there any know workaround? > > Looking on Google there is a thread: > i386_set_ldt and wine on AMD64 which mentions some patches by kib > but no mention if this ever worked. > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=233316+0+archive/2008/freebsd-amd64/20081214.freebsd-amd64 > > The latest version I can find is: > http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch > > Anyone info appreciated. The patches were committed to HEAD. mplayer/win32 codecs were tested, it was one of the goal of the patch to have these codecs working on amd64. No MFC to 7.x is planned. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090719/411ec300/attachment.pgp From killing at multiplay.co.uk Sun Jul 19 14:29:52 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sun Jul 19 14:30:04 2009 Subject: i386_set_ldt on FreeBSD 7.x amd64 References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> Message-ID: ----- Original Message ----- From: "Kostik Belousov" >> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=233316+0+archive/2008/freebsd-amd64/20081214.freebsd-amd64 >> >> The latest version I can find is: >> http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch > > Anyone info appreciated. > The patches were committed to HEAD. mplayer/win32 codec's were tested, > it was one of the goal of the patch to have these codec's working on amd64. > > No MFC to 7.x is planned. Thanks for the confirmation Kostik. Do you believe there is any reason to stop that patch working on 7.X if manually applied? Is the patch above the final version that went into HEAD? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From kostikbel at gmail.com Sun Jul 19 15:11:47 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Jul 19 15:11:54 2009 Subject: i386_set_ldt on FreeBSD 7.x amd64 In-Reply-To: References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> Message-ID: <20090719151141.GZ55190@deviant.kiev.zoral.com.ua> On Sun, Jul 19, 2009 at 03:29:51PM +0100, Steven Hartland wrote: > ----- Original Message ----- > From: "Kostik Belousov" > >>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=233316+0+archive/2008/freebsd-amd64/20081214.freebsd-amd64 > >> > >>The latest version I can find is: > >>http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch > > > >Anyone info appreciated. > >The patches were committed to HEAD. mplayer/win32 codec's were tested, > >it was one of the goal of the patch to have these codec's working on amd64. > > > >No MFC to 7.x is planned. > > Thanks for the confirmation Kostik. Do you believe there is any reason to > stop that patch working on 7.X if manually applied? Is the patch above the > final version that went into HEAD? No and no, but I think that back-porting is not that trivial. Upgrade is probably easier then backport. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090719/2c94a4f1/attachment.pgp From killing at multiplay.co.uk Sun Jul 19 16:28:31 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sun Jul 19 16:28:39 2009 Subject: i386_set_ldt on FreeBSD 7.x amd64 References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> <20090719151141.GZ55190@deviant.kiev.zoral.com.ua> Message-ID: ----- Original Message ----- From: "Kostik Belousov" >> Thanks for the confirmation Kostik. Do you believe there is any reason to >> stop that patch working on 7.X if manually applied? Is the patch above the >> final version that went into HEAD? > > No and no, but I think that back-porting is not that trivial. > Upgrade is probably easier then backport. When you say HEAD would that require an upgrade to 7-STABLE or 8-CURRENT? I never did get what the official meaning of HEAD is, as it seems to be used by different people to mean both of the above. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From ed at 80386.nl Sun Jul 19 20:07:37 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Jul 19 20:07:49 2009 Subject: i386_set_ldt on FreeBSD 7.x amd64 In-Reply-To: References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> <20090719151141.GZ55190@deviant.kiev.zoral.com.ua> Message-ID: <20090719200735.GG68469@hoeg.nl> Hi Steven, * Steven Hartland wrote: > When you say HEAD would that require an upgrade to 7-STABLE or 8-CURRENT? Right now HEAD (or head/ in SVN) is 8-CURRENT. RELENG_7 (or stable/7) is 7-STABLE. -- Ed Schouten WWW: http://80386.nl/ From kaduk at MIT.EDU Mon Jul 20 05:18:38 2009 From: kaduk at MIT.EDU (Benjamin Kaduk) Date: Mon Jul 20 05:18:45 2009 Subject: add missing content to locking.9 ? Message-ID: Hi all, In trying to track down an unrelated issue, I happened to note that locking.9 needed a bit of help. They easy changes went into docs/136918, but I am less confident about my reading of the posix semaphore code. Would anyone care to comment on the following?: --- locking.9 2009-07-20 00:34:46.000000000 -0400 +++ locking.9.new 2009-07-20 00:31:27.000000000 -0400 @@ -215,6 +215,11 @@ a turnstile, its priority can propagate to the thread that holds the lock, helping to avoid a deadlock situation. .Ss Semaphores +.Tn POSIX +semaphores provide a wait channel in the filesystem namespace +whereby different threads can communicate with each other (by waiting +on the semaphore, and waking up the thread(s) waiting on that semaphore). +They are currently implemented on top of condition variables. .Ss Condition variables Condition variables are used in conjunction with mutexes to wait for conditions to occur. It should also be noted that there remains a comment "I don't know what the downsides are but I'm sure someone will fill in this part" regarding lockmgr locks ... I am not up for reading the code enough to comment, tonight, though. Thanks, Ben Kaduk From mel.flynn+fbsd.hackers at mailing.thruhere.net Mon Jul 20 06:27:26 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Mon Jul 20 06:27:33 2009 Subject: mmap/munmap with zero length In-Reply-To: <200907131639.10346.jhb@freebsd.org> References: <200907131428.08923.jhb@freebsd.org> <200907132133.52217.tijl@ulyssis.org> <200907131639.10346.jhb@freebsd.org> Message-ID: On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin wrote: > On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote: >> On Monday 13 July 2009 20:28:08 John Baldwin wrote: >> > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: >> >> so mmap differs from the POSIX recommendation right. the malloc.conf >> >> option seems more like a workaround/hack. imo it's confusing to have >> >> mmap und munmap deal differently with len=0. being able to >> >> succesfully alocate memory which cannot be removed doesn't seem >> >> logical to me. >> > >> > This should fix it: >> > >> > --- //depot/user/jhb/acpipci/vm/vm_mmap.c >> > +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c >> > @@ -229,7 +229,7 @@ >> > >> > fp = NULL; >> > /* make sure mapping fits into numeric range etc */ >> > - if ((ssize_t) uap->len < 0 || >> > + if ((ssize_t) uap->len <= 0 || >> > ((flags & MAP_ANON) && uap->fd != -1)) >> > return (EINVAL); >> >> Why not "uap->len == 0"? Sizes of 2GiB and more (32bit) shouldn't cause >> an error. > > I don't actually disagree and know of locally modified versions of FreeBSD > that remove this check for precisely that reason. If this has hit the tree recently, I think it broke ccache. Since I've also done make delete-old-libs and was about to rebuild all my ports on my laptop, I'll investigate, as I'm not looking forward to doing this twice for all dependants of libtool :(. Failed to mmap /var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934 kdump: 27934 ccache CALL open(0x28201280,O_RDONLY,0x1) 27934 ccache NAMI "/var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934" 27934 ccache RET open 4 27934 ccache CALL fstat(0x4,0xbfbfe7fc) 27934 ccache STRU struct stat {dev=105, ino=895320, mode=-rw-r--r-- , nlink=1, uid=1003, gid=0, rdev=0, atime=1248069251, stime=1248069251, ctime=1248069251, birthtime=1248069251, size=0, blksize=4096, blocks=0, flags=0x0 } 27934 ccache RET fstat 0 27934 ccache CALL mmap(0,0,PROT_READ,MAP_PRIVATE,0x4,0,0) 27934 ccache RET mmap -1 errno 22 Invalid argument Sent from webmail, so excuse any formatting issues. -- Mel From mel.flynn+fbsd.hackers at mailing.thruhere.net Mon Jul 20 07:07:32 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Mon Jul 20 07:07:39 2009 Subject: mmap/munmap with zero length In-Reply-To: References: <200907131428.08923.jhb@freebsd.org> <200907132133.52217.tijl@ulyssis.org> <200907131639.10346.jhb@freebsd.org> Message-ID: <55daf4085f8ce3b4e383e36ba502bdec@sbmail.office-on-the.net> On Sun, 19 Jul 2009 22:13:48 -0800, Mel Flynn wrote: > On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin wrote: >> On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote: >>> On Monday 13 July 2009 20:28:08 John Baldwin wrote: >>> > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: >>> >> so mmap differs from the POSIX recommendation right. the malloc.conf >>> >> option seems more like a workaround/hack. imo it's confusing to have >>> >> mmap und munmap deal differently with len=0. being able to >>> >> succesfully alocate memory which cannot be removed doesn't seem >>> >> logical to me. >>> > >>> > This should fix it: >>> > >>> > --- //depot/user/jhb/acpipci/vm/vm_mmap.c >>> > +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c >>> > @@ -229,7 +229,7 @@ >>> > >>> > fp = NULL; >>> > /* make sure mapping fits into numeric range etc */ >>> > - if ((ssize_t) uap->len < 0 || >>> > + if ((ssize_t) uap->len <= 0 || >>> > ((flags & MAP_ANON) && uap->fd != -1)) >>> > return (EINVAL); >>> >>> Why not "uap->len == 0"? Sizes of 2GiB and more (32bit) shouldn't cause >>> an error. >> >> I don't actually disagree and know of locally modified versions of > FreeBSD >> that remove this check for precisely that reason. > > If this has hit the tree recently, I think it broke ccache. > > Since I've also done make delete-old-libs and was about to rebuild all my > ports on my laptop, I'll investigate, as I'm not looking forward to doing > this twice for all dependants of libtool :(. > > Failed to mmap > /var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934 > > kdump: > 27934 ccache CALL open(0x28201280,O_RDONLY,0x1) > 27934 ccache NAMI > "/var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934" > 27934 ccache RET open 4 > 27934 ccache CALL fstat(0x4,0xbfbfe7fc) > 27934 ccache STRU struct stat {dev=105, ino=895320, mode=-rw-r--r-- , > nlink=1, uid=1003, gid=0, rdev=0, atime=1248069251, stime=1248069251, > ctime=1248069251, birthtime=1248069251, size=0, blksize=4096, blocks=0, > flags=0x0 } > 27934 ccache RET fstat 0 > 27934 ccache CALL mmap(0,0,PROT_READ,MAP_PRIVATE,0x4,0,0) > 27934 ccache RET mmap -1 errno 22 Invalid argument Confirmed, attached patch fixes ccache. Probably should be patched in patch-md4. -- Mel -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-mmap Type: application/octet-stream Size: 790 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090720/9bc71e56/patch-mmap.obj From avg at icyb.net.ua Mon Jul 20 11:17:49 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Jul 20 11:17:57 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <4A61D6FB.2090904@elischer.org> References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> <20090718081011.GA6920@curry.mchp.siemens.de> <4A61D6FB.2090904@elischer.org> Message-ID: <4A644F7E.2000107@icyb.net.ua> on 18/07/2009 17:06 Julian Elischer said the following: > Andre Albsmeier wrote: >> But in order to attach to acpi0, I need to say >> >> DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, >> NULL ); >> >> instead of >> >> DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, >> NULL ); > > try both with different devclass and other args. Just to expand on Julian's words. You can create eccmon and e.g. eccmon_acpi such that they are different drivers (on different buses) in newbus sense, but logically they can share data or otherwise cooperate. /sys/dev/cpufreq/ichss.c prior to rev. 177041 used to be like that. -- Andriy Gapon From ed at 80386.nl Mon Jul 20 12:36:10 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Jul 20 12:36:16 2009 Subject: add missing content to locking.9 ? In-Reply-To: References: Message-ID: <20090720123607.GI68469@hoeg.nl> Hi Benjamin, * Benjamin Kaduk wrote: > +.Tn POSIX > +semaphores provide ... it looks like you described the semaphores that are used in userspace. The Semaphores section of the locking(9) man page should describe in-kernel semaphores (kern_sema.c). They are implemented by a mutex and a conditional variable. Even though it's nice to have some utility functions in our kernel, I always wondered why we have them. There isn't a lot of code in the tree that uses them... -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090720/36247438/attachment.pgp From brampton+freebsd-hackers at gmail.com Mon Jul 20 15:14:07 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Mon Jul 20 15:14:13 2009 Subject: vm_map_protect / pmap_protect Can't lower protection Message-ID: Hi, I've been playing with memguard(9) and so far it works well until it starts to run out of memory. For those who don't know, memguard is a replacement debugging malloc for the kernel, which is designed to catch use after free errors. It achieves this by setting any free'd pages to read-only, therefore any writes to the page should generate a page fault, and a backtrace allowing you to figure out where your code is using freed memory. To stop memguard using all your system's RAM and setting every page to read-only, it begins to recycle previously freed pages. To do this it must first make the page read-write, and then return it from malloc. The problem I am facing is when memguard, unguards a page (ie changes the page to read-write) it does not actually do this, and the page remains read-only. I have tracked the problem down but I don't know how to fix it. memguard_guard calls vm_map_protect with a read-only flag. vm_map_protect updates the vm_map_entry, and then calls pmap_protect to set the actual pte. pmap_protect successfully sets the pte to read-only and everything works as it should. However, memguard_unguard doesn't work correctly. It first calls vm_map_protect with a read-write flag. vm_map_protect correctly updates the vm_map_entry, and then calls pmap_protect to set the actual pte. pmap_protect is lazy and notices that we are reducing the protection on the page and therefore does nothing. It assumes that later that a page fault will occur, call vm_fault, and then fix up the pte then. The problem I seem to be having is that vm_fault is not called, because when the page fault occurs, calltrap then trap gets called, but it falls into trap_fatal because a non-sleepable lock is held. So my question is, can I call a function which sets the pte in a non-lazy way? I considered rewriting pmap_protect to do this, but I thought it be best to do it another way. Another idea I had was to call vm_fault myself straight after vm_map_protect, but I was unsure if that was allowed. Also, some googling found the function pmap_page_protect claims to do what I want, but has long been missing from FreeBSD. In case it matters, I'm using FreeBSD 7.2, on a amd64 machine. I've looked at HEAD and the relevant code looks the same, so I suspect I will still have problems with that. thanks for any help Andrew From Andre.Albsmeier at siemens.com Mon Jul 20 18:26:25 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Mon Jul 20 18:26:32 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <4A644F7E.2000107@icyb.net.ua> References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> <20090718081011.GA6920@curry.mchp.siemens.de> <4A61D6FB.2090904@elischer.org> <4A644F7E.2000107@icyb.net.ua> Message-ID: <20090720182620.GA90731@curry.mchp.siemens.de> On Mon, 20-Jul-2009 at 14:05:34 +0300, Andriy Gapon wrote: > on 18/07/2009 17:06 Julian Elischer said the following: > > Andre Albsmeier wrote: > >> But in order to attach to acpi0, I need to say > >> > >> DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > >> NULL ); > >> > >> instead of > >> > >> DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > >> NULL ); > > > > try both with different devclass and other args. > > Just to expand on Julian's words. > You can create eccmon and e.g. eccmon_acpi such that they are different drivers > (on different buses) in newbus sense, but logically they can share data or > otherwise cooperate. Very interesting code, I still haven't understood all of it but we will see... This could be the solution -- however, if somebody knows a more simple way, please let me know. Thanks, -Andre > > /sys/dev/cpufreq/ichss.c prior to rev. 177041 used to be like that. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Amateurs like Linux, but professionals prefer FreeBSD. From jhb at freebsd.org Mon Jul 20 21:35:59 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 20 21:36:11 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <20090718133938.GA7802@curry.mchp.siemens.de> References: <20090717190450.GA4697@curry.mchp.siemens.de> <20090718133938.GA7802@curry.mchp.siemens.de> Message-ID: <200907201046.58558.jhb@freebsd.org> On Saturday 18 July 2009 9:39:38 am Andre Albsmeier wrote: > On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > > > > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > > >> Andre Albsmeier wrote: > > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > > >>> > > >>> Since my driver is a child of hostb0, I have no idea of how to > > >>> access > > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > > >>> > > >> ... > > >>> > > >>> Earlier, I was given the hint to attach as a child of acpi (see the > > >>> old mail attached below) but in this case I didn't have access to > > >>> the > > >>> hostb registers which I need as well. > > >>> > > >>> The only thing I see is: Attach two drivers -- one as child of acpi > > >>> and another as child of hostb and let them communicate somehow (no > > >>> idea how to do this). > > >>> > > >>> I have also done crazy things like searching for acpi0 and trying > > >>> to bus_alloc_resource() the memory I am interested in but this also > > >>> failed. > > >>> > > >>> Or is it possible to free(!) somehow the address space from acpi0 > > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > > >>> > > >> > > >> You can probably make two drivers in one which cooperate to > > >> allow access to both sets of resources. > > > > > > Hmm, that's what I meant by: Attach two drivers -- one as child of > > > acpi > > > and another as child of hostb... > > > > > > And that's similar to Rui Paulo's suggestion a while ago: > > > > > >> You'll probably need to create a fake ACPI child driver to access it. > > >> > > >> Create your identify routine with something like: > > >> > > >> static void mydriver_identify(driver_t *driver, device_t parent) > > >> { > > >> if (device_find_child(parent, "mydriver", -1) == NULL && > > >> mydriver_match(parent)) > > >> device_add_child(parent, "mydriver", -1); > > >> } > > >> > > >> mydriver_match() should check if you were given the acpi0 device. > > > > > > But in order to attach to acpi0, I need to say > > > > > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > > > NULL ); > > > > > > instead of > > > > > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > > > NULL ); > > > > > > This way I could attach to acpi but not to hostb anymore.... > > > > > > I have searched the net for solutions, I have read newbus-draft.txt > > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > > > of these my driver is working on other mainboards where it doesn't > > > have to access foreign memory) but didn't find anything. > > > > I'm out of ideas. > > John, do you know if this is a newbus limitation or if it can be > > worked around ? > > I assume it is possible somehow, I am just too stupid (it is the first > driver I wrote). John, for easy reference, here is my initial message: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > > Please remember all, that I need the access to the acpi0 memory location > only for a few reads during probing/attaching, not later. > > I have also read somewhere that, when resources are allocated, the > system "walks up" the device tree until it finds the resource. Since > my driver is below hostb0 and hostb0 is below acpi0 I thought it > should work but it doesn't.. I think you want to probably patch hostb0 to let bus_set_resource() work and then use that. You could also just explicitly by-pass hostb0 and allocate a resource from its parent as a quick hack. The PCI bus should pass the requst up to acpi0. That is, do: BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), dev, ...); instead of bus_alloc_resource(dev, ...); -- John Baldwin From killing at multiplay.co.uk Tue Jul 21 02:33:23 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Tue Jul 21 02:33:35 2009 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade References: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> Message-ID: <415DF72E19E24DBEA840BAB408A3442E@multiplay.co.uk> Did anyone ever get anywhere with this, just retried with 8.0-BETA2 and still the same hangs as depicted in the attached screen shots. Sorry got no serial console :( Would like to get this working if possible so anything I can try to gain some more info on this issue? Regards Steve ----- Original Message ----- From: "Adam Jacob Muller" > > Anyone ever get this to work? Perhaps this was fixed in a newer > FreeBSD? Have some M600 that i'd like to get FreeBSD running on :) > > hint.apic.0.disabled seemed to change things a bit, it would reach ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From wsw1wsw2 at gmail.com Tue Jul 21 05:02:33 2009 From: wsw1wsw2 at gmail.com (Shaowei Wang (wsw)) Date: Tue Jul 21 05:02:39 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? Message-ID: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> Hi, hackers! Recently I am playing the clangbsd i386 branch and it works. I've noticed that clang using gcc to linking object code or even doing assembling. clang from FreeBSD perspective will be a whole compiler tool chain or just another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? Thanks -wsw From rdivacky at freebsd.org Tue Jul 21 13:36:49 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Jul 21 13:36:57 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> Message-ID: <20090721131735.GA18929@freebsd.org> On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > Hi, hackers! > > Recently I am playing the clangbsd i386 branch and it works. I've noticed > that clang using gcc to linking object code or even doing assembling. > > clang from FreeBSD perspective will be a whole compiler tool chain or just > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? llvm people are working on "mc" which is a native assembler/dissasembler. so the only part of the toolchain missing will be linker... now we need as/ld (and gnu driver that knows how to talk to them) roman From ed at 80386.nl Tue Jul 21 19:20:45 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Jul 21 19:20:52 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> Message-ID: <20090721192043.GK68469@hoeg.nl> Hi, * Shaowei Wang (wsw) wrote: > Recently I am playing the clangbsd i386 branch and it works. I've noticed > that clang using gcc to linking object code or even doing assembling. No, this is not true. It calls ld and as to do the linking/assembling. Some stuff in the clangbsd branch still gets built with GCC, because of regressions/missing features of Clang. Yours, -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090721/f3fb123a/attachment.pgp From alexbestms at math.uni-muenster.de Tue Jul 21 22:43:23 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Jul 21 22:43:30 2009 Subject: checking number of parallel ports installed and their port adresses Message-ID: hi there, i've written an app in c (and a bit of asm) which needs to do raw parallel port io using the i386 opcodes in/out. to get the number of available parallel ports installed and their addresses i open and mmap /dev/mem and read the address-values from the BIOS area @ 0x408. is there a better way to find out the number of parallel ports installed and their addresses? cheers. From wsw1wsw2 at gmail.com Wed Jul 22 01:18:48 2009 From: wsw1wsw2 at gmail.com (Shaowei Wang (wsw)) Date: Wed Jul 22 01:18:54 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <20090721131735.GA18929@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> Message-ID: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky wrote: > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > Hi, hackers! > > > > Recently I am playing the clangbsd i386 branch and it works. I've noticed > > that clang using gcc to linking object code or even doing assembling. > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > just > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > llvm people are working on "mc" which is a native assembler/dissasembler. > so the only part of the toolchain missing will be linker... now we > need as/ld (and gnu driver that knows how to talk to them) So what's the direction? Are we going to cut off all the GNU compiler tool chains and use the llvm/clang when it's mature. > > > roman > From des at des.no Wed Jul 22 01:38:46 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Jul 22 01:38:52 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> (Shaowei Wang's message of "Wed, 22 Jul 2009 09:18:46 +0800") References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> Message-ID: <864ot5jy3f.fsf@ds4.des.no> "Shaowei Wang (wsw)" writes: > So what's the direction? Are we going to cut off all the GNU compiler > tool chains and use the llvm/clang when it's mature. Who's "we"? Anyway, LLVM *isn't* mature, and it probably won't be for years, if ever, so there's no point in asking. If it ever reaches a point where it covers our needs, and it's still under an acceptable license, and somebody sits down and does the work and assumes the responsibility, and portsmgr@ doesn't have a conniption because it breaks half the ports tree, and core@ approves, and a majority of developers approve, including those who think we should run with pcc instead but can't be arsed to do the work, then maybe. At this point, speculating about it is just a waste of time and electrons. DES -- Dag-Erling Sm?rgrav - des@des.no From kitchetech at gmail.com Wed Jul 22 01:59:34 2009 From: kitchetech at gmail.com (matt donovan) Date: Wed Jul 22 01:59:41 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> Message-ID: <28283d910907211827o3189760y6531f9cebb081adf@mail.gmail.com> On Tue, Jul 21, 2009 at 9:18 PM, Shaowei Wang (wsw) wrote: > On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky > wrote: > > > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > > Hi, hackers! > > > > > > Recently I am playing the clangbsd i386 branch and it works. I've > noticed > > > that clang using gcc to linking object code or even doing assembling. > > > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > > just > > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > > > llvm people are working on "mc" which is a native assembler/dissasembler. > > so the only part of the toolchain missing will be linker... now we > > need as/ld (and gnu driver that knows how to talk to them) > > > So what's the direction? Are we going to cut off all the GNU compiler tool > chains and use the llvm/clang when it's mature. > > > > > > > > > roman > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Well I did build 8.0-Beta2 with clang the latest svn though seems to have broke the usb compile for me. Most likely due to a commit that was done but clang is pretty mature to compile most things but for now I just have CC=/usr/bin/gcc in my make.conf to build ports From rdivacky at freebsd.org Wed Jul 22 07:21:59 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed Jul 22 07:22:07 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> Message-ID: <20090722071956.GA89631@freebsd.org> On Wed, Jul 22, 2009 at 09:18:46AM +0800, Shaowei Wang (wsw) wrote: > On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky wrote: > > > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > > Hi, hackers! > > > > > > Recently I am playing the clangbsd i386 branch and it works. I've noticed > > > that clang using gcc to linking object code or even doing assembling. > > > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > > just > > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > > > llvm people are working on "mc" which is a native assembler/dissasembler. > > so the only part of the toolchain missing will be linker... now we > > need as/ld (and gnu driver that knows how to talk to them) > > > So what's the direction? Are we going to cut off all the GNU compiler tool > chains and use the llvm/clang when it's mature. there is no official stand on this but I guess the framework to enable optional usage of clang as "cc" instead of gcc might be committed "soon"... but that does not switch anything. there's quite a lot of work still to do (on both fbsd and clang/llvm side). things have stalled a little recently - it's summer, people got distracted, code freeze etc. but at least I am going to push some more work on this after the freeze/summer... this is my personal view not representing anything official in FreeBSD roman From wsw1wsw2 at gmail.com Wed Jul 22 07:30:45 2009 From: wsw1wsw2 at gmail.com (Shaowei Wang (wsw)) Date: Wed Jul 22 07:30:51 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <20090722071956.GA89631@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <20090722071956.GA89631@freebsd.org> Message-ID: <2e566b9e0907220030p6e5f0233qcc527acdd5c55dfc@mail.gmail.com> On Wed, Jul 22, 2009 at 3:19 PM, Roman Divacky wrote: > On Wed, Jul 22, 2009 at 09:18:46AM +0800, Shaowei Wang (wsw) wrote: > > On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky > wrote: > > > > > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > > > Hi, hackers! > > > > > > > > Recently I am playing the clangbsd i386 branch and it works. I've > noticed > > > > that clang using gcc to linking object code or even doing assembling. > > > > > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > > > just > > > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > > > > > llvm people are working on "mc" which is a native > assembler/dissasembler. > > > so the only part of the toolchain missing will be linker... now we > > > need as/ld (and gnu driver that knows how to talk to them) > > > > > > So what's the direction? Are we going to cut off all the GNU compiler > tool > > chains and use the llvm/clang when it's mature. > > there is no official stand on this but I guess the framework to enable > optional > usage of clang as "cc" instead of gcc might be committed "soon"... This sounds great. > > but that does not switch anything. there's quite a lot of work still to do > (on both fbsd and clang/llvm side). things have stalled a little recently > - it's summer, people got distracted, code freeze etc. but at least I am > going > to push some more work on this after the freeze/summer... > Yeah, I know. still a lot of work... > > this is my personal view not representing anything official in FreeBSD > > roman > From kostikbel at gmail.com Wed Jul 22 14:18:04 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jul 22 14:18:10 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <864ot5jy3f.fsf@ds4.des.no> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> Message-ID: <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> On Wed, Jul 22, 2009 at 03:38:44AM +0200, Dag-Erling Sm??rgrav wrote: > "Shaowei Wang (wsw)" writes: > > So what's the direction? Are we going to cut off all the GNU compiler > > tool chains and use the llvm/clang when it's mature. > > Who's "we"? > > Anyway, LLVM *isn't* mature, and it probably won't be for years, if > ever, so there's no point in asking. If it ever reaches a point where > it covers our needs, and it's still under an acceptable license, and > somebody sits down and does the work and assumes the responsibility, and > portsmgr@ doesn't have a conniption because it breaks half the ports > tree, and core@ approves, and a majority of developers approve, > including those who think we should run with pcc instead but can't be > arsed to do the work, then maybe. At this point, speculating about it > is just a waste of time and electrons. I believe that the nearest action that is quite reasonable and profitable by its own merit is divorcing base compiler and compiler used to build ports. Even if this means that we would "only" have different versions of gcc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090722/21dd0881/attachment.pgp From alexanderchuranov at gmail.com Wed Jul 22 15:49:13 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Wed Jul 22 15:49:18 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> Message-ID: <3cb459ed0907220823q2376f545x44c0972a989a4b72@mail.gmail.com> 2009/7/22 Kostik Belousov : > I believe that the nearest action that is quite reasonable and > profitable by its own merit is divorcing base compiler and compiler used > to build ports. Even if this means that we would "only" have different > versions of gcc. > I know some ports using "USE_GCC" knob of /usr/ports/Mk/bsd.gcc.mk . Is this the same as you suggest? Alexander Churanov From kostikbel at gmail.com Wed Jul 22 16:05:57 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jul 22 16:06:03 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <3cb459ed0907220823q2376f545x44c0972a989a4b72@mail.gmail.com> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> <3cb459ed0907220823q2376f545x44c0972a989a4b72@mail.gmail.com> Message-ID: <20090722160547.GU55190@deviant.kiev.zoral.com.ua> On Wed, Jul 22, 2009 at 07:23:17PM +0400, Alexander Churanov wrote: > 2009/7/22 Kostik Belousov : > > I believe that the nearest action that is quite reasonable and > > profitable by its own merit is divorcing base compiler and compiler used > > to build ports. Even if this means that we would "only" have different > > versions of gcc. > > > > I know some ports using "USE_GCC" knob of /usr/ports/Mk/bsd.gcc.mk . > Is this the same as you suggest? No. And this was actually not my idea. The proposal is to have portmgr-selected and approved version of gcc, installed from port and used to build ports. The base (g)cc is used only to build base. Such divorce seems to be beneficial both to base compiler, and for ports. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090722/6bd527ec/attachment.pgp From igor at hybrid-lab.co.uk Wed Jul 22 16:17:09 2009 From: igor at hybrid-lab.co.uk (Igor Mozolevsky) Date: Wed Jul 22 16:17:15 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> Message-ID: 2009/7/22 Kostik Belousov : > I believe that the nearest action that is quite reasonable and > profitable by its own merit is divorcing base compiler and compiler used > to build ports. Even if this means that we would "only" have different > versions of gcc. On a similar note, has anyone one tried clang + yasm? Cheers, -- Igor From ed at 80386.nl Wed Jul 22 16:20:38 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Jul 22 16:20:45 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <864ot5jy3f.fsf@ds4.des.no> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> Message-ID: <20090722162036.GO68469@hoeg.nl> * Dag-Erling Sm?rgrav wrote: > "Shaowei Wang (wsw)" writes: > > So what's the direction? Are we going to cut off all the GNU compiler > > tool chains and use the llvm/clang when it's mature. > > Who's "we"? > > Anyway, LLVM *isn't* mature, and it probably won't be for years, if > ever, so there's no point in asking. Even though "if ever" sounds a little bit pessimistic, I agree. Unfortunately I'm busy working on other things the last couple of weeks/months, but the biggest problem with LLVM/Clang right now is that the latest release on the website is practically useless to us. I've been tracking SVN, but each time I decide to upgrade sources, I get yet another regression, which means I have to file bug reports. I think I already filed 50-60 bug reports. For some reason there has been a lot of talking, but no hacking. It takes a lot of work to maintain ClangBSD, at least more than I'm willing to spend on it right now. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090722/b1e1b2be/attachment.pgp From shuvaev at physik.uni-wuerzburg.de Wed Jul 22 16:29:26 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Wed Jul 22 16:29:33 2009 Subject: checking number of parallel ports installed and their port adresses In-Reply-To: References: Message-ID: <20090722162920.GA57243@wep4035.physik.uni-wuerzburg.de> On Wed, Jul 22, 2009 at 12:43:20AM +0200, Alexander Best wrote: > hi there, > > i've written an app in c (and a bit of asm) which needs to do raw parallel > port io using the i386 opcodes in/out. to get the number of available parallel > ports installed and their addresses i open and mmap /dev/mem and read the > address-values from the BIOS area @ 0x408. is there a better way to find out > the number of parallel ports installed and their addresses? > Why not to use /dev/ppi interface? man 4 ppi It is in GENERIC kernel. You don't need assembler then. You can look at your dmesg to count all ppc parallel ports: [snip] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 [snip] Alexey. From alexbestms at math.uni-muenster.de Wed Jul 22 19:31:59 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Jul 22 19:32:07 2009 Subject: checking number of parallel ports installed and their port adresses In-Reply-To: <20090722162920.GA57243@wep4035.physik.uni-wuerzburg.de> Message-ID: the ppi manual states that using ioctl with /dev/ppi is extremely slow. i need the parallel port to be really fast. i need to communicate with a device that uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full ISA bus speed to be able to push/pull data to/from the parallel port without any delays. timing is really critical. if there's a lot of work to do for the scheduler and the io calls get queued too long the transfer will fail. plus i want the app to be linux compatible and i don't think ppi exists on linux. actually i meant: how can i check the available parallel ports from within my app? is there a syscall i can use or something like that? cheers. alex Alexey Shuvaev schrieb am 2009-07-22: > On Wed, Jul 22, 2009 at 12:43:20AM +0200, Alexander Best wrote: > > hi there, > > i've written an app in c (and a bit of asm) which needs to do raw > > parallel > > port io using the i386 opcodes in/out. to get the number of > > available parallel > > ports installed and their addresses i open and mmap /dev/mem and > > read the > > address-values from the BIOS area @ 0x408. is there a better way to > > find out > > the number of parallel ports installed and their addresses? > Why not to use /dev/ppi interface? > man 4 ppi > It is in GENERIC kernel. > You don't need assembler then. > You can look at your dmesg to count all ppc parallel ports: > [snip] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on > acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > [snip] > Alexey. From rdivacky at freebsd.org Wed Jul 22 20:24:37 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed Jul 22 20:24:46 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> Message-ID: <20090722202235.GA28313@freebsd.org> On Wed, Jul 22, 2009 at 04:52:58PM +0100, Igor Mozolevsky wrote: > 2009/7/22 Kostik Belousov : > > > I believe that the nearest action that is quite reasonable and > > profitable by its own merit is divorcing base compiler and compiler used > > to build ports. Even if this means that we would "only" have different > > versions of gcc. > > > On a similar note, has anyone one tried clang + yasm? I did.. it does not work.... and there is no future in this. clang/llvm is getting native elf writer/assembler really soon From rdivacky at freebsd.org Wed Jul 22 20:26:36 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed Jul 22 20:26:43 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <20090722162036.GO68469@hoeg.nl> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722162036.GO68469@hoeg.nl> Message-ID: <20090722202433.GA28586@freebsd.org> On Wed, Jul 22, 2009 at 06:20:36PM +0200, Ed Schouten wrote: > * Dag-Erling Sm?rgrav wrote: > > "Shaowei Wang (wsw)" writes: > > > So what's the direction? Are we going to cut off all the GNU compiler > > > tool chains and use the llvm/clang when it's mature. > > > > Who's "we"? > > > > Anyway, LLVM *isn't* mature, and it probably won't be for years, if > > ever, so there's no point in asking. > > Even though "if ever" sounds a little bit pessimistic, I agree. > > Unfortunately I'm busy working on other things the last couple of > weeks/months, but the biggest problem with LLVM/Clang right now is that > the latest release on the website is practically useless to us. I've > been tracking SVN, but each time I decide to upgrade sources, I get yet > another regression, which means I have to file bug reports. I think I > already filed 50-60 bug reports. > > For some reason there has been a lot of talking, but no hacking. It > takes a lot of work to maintain ClangBSD, at least more than I'm willing > to spend on it right now. I know you disagree with me but from my pov clangbsd is mostly finished. the integration is "just fine". what we need to do now is to get clang/llvm and freebsd sources into shapes so there are no problems compiling freebsd with clang. most of the problems is with clang but there are things to improve in freebsd too. I am working (and others as well) on both. roman From ap00 at mail.ru Wed Jul 22 22:05:16 2009 From: ap00 at mail.ru (Anthony Pankov) Date: Wed Jul 22 22:05:23 2009 Subject: SGID/SUID on scripts Message-ID: <19939654343.20090722214221@mail.ru> SGID/SUID bits don't work with shell scripts, do they? And no mention in chmod(1,2) manual. -- Best regards, Anthony mailto:ap00@mail.ru From julian at elischer.org Wed Jul 22 23:02:02 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Jul 22 23:02:15 2009 Subject: SGID/SUID on scripts In-Reply-To: <19939654343.20090722214221@mail.ru> References: <19939654343.20090722214221@mail.ru> Message-ID: <4A679A6B.70905@elischer.org> Anthony Pankov wrote: > SGID/SUID bits don't work with shell scripts, do they? No google SUID script security > > And no mention in chmod(1,2) manual. > > > From darksoul at darkbsd.org Wed Jul 22 23:02:05 2009 From: darksoul at darkbsd.org (DarkSoul) Date: Wed Jul 22 23:05:22 2009 Subject: SGID/SUID on scripts In-Reply-To: <19939654343.20090722214221@mail.ru> References: <19939654343.20090722214221@mail.ru> Message-ID: <4A6795E7.7020700@darkbsd.org> Anthony Pankov wrote: > SGID/SUID bits don't work with shell scripts, do they? > > And no mention in chmod(1,2) manual. They don't. One reason for this, is that if they were applied, the following would occur : - execve() syscall reads your script's shebang line, and the script interpreter is executed, receiving the specified arguments along with the script name. - The interpreter then open()s the script file to read it, and run the code. The problem you then are faced with, is that you have a time frame defined by the moment between the aforementioned execve() and open(), during which it could be possible to unlink/move/whatever the shell script the interpreter is going to open. You guess where this is going, you have no absolute way of guaranteeing you are executing the file you initially planned on opening because execution/opening/reading is not, and can't be done atomically for shell scripts. Cheers, -- Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090722/4350f132/signature.pgp From perryh at pluto.rain.com Thu Jul 23 05:44:40 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Thu Jul 23 05:44:46 2009 Subject: SGID/SUID on scripts In-Reply-To: <4A6795E7.7020700@darkbsd.org> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> Message-ID: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> DarkSoul wrote: > Anthony Pankov wrote: > > SGID/SUID bits don't work with shell scripts, do they? > > They don't. > > ... if they were applied, the following would occur : > - execve() syscall reads your script's shebang line, and > the script interpreter is executed, receiving the specified > arguments along with the script name. > - The interpreter then open()s the script file to read it, > and run the code. > > The problem you then are faced with, is that you have a time > frame defined by the moment between the aforementioned execve() > and open(), during which it could be possible to unlink/move/ > whatever the shell script the interpreter is going to open. > > You guess where this is going, you have no absolute way of > guaranteeing you are executing the file you initially planned > on opening because execution/opening/reading is not, and can't > be done atomically for shell scripts. In principle, it should be possible to fix this exposure by improving the interface between execve() and the interpreter: The execve() syscall already has the script file open to read the shebang line. Leave it open, and ensure that the interpreter receives the open descriptor as fd#3 just as 0, 1, and 2 are already used for stdin, stdout, and stderr. An interpreter supporting this approach would check whether stdscr (fd#3) is already open, and if so read from it instead of open()ing the script file. This should ensure that the script which gets executed is the same inode on which execve() saw the SGID/SUID bits set, even if the filesystem has been changed by the time the interpreter has gotten started. It would be the responsibility of whomever decided to set the SGID/SUID bits on a particular script to ensure that the interpreter involved supports the mechanism. I vaguely recall having seen a similar (or even identical) approach suggested some years ago. It may even have been implemented in some variant of Un*x. From Andre.Albsmeier at siemens.com Thu Jul 23 06:08:40 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Thu Jul 23 06:08:47 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <200907221648.n6MGmu58035040@ambrisko.com> References: <20090718133938.GA7802@curry.mchp.siemens.de> <200907221648.n6MGmu58035040@ambrisko.com> Message-ID: <20090723060835.GB62628@curry.mchp.siemens.de> On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > Andre Albsmeier writes: > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > | > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > | > >> Andre Albsmeier wrote: > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > | > >>> > | > >>> Since my driver is a child of hostb0, I have no idea of how to > | > >>> access > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > | > >>> > | > >> ... > | > >>> > | > >>> Earlier, I was given the hint to attach as a child of acpi (see the > | > >>> old mail attached below) but in this case I didn't have access to > | > >>> the > | > >>> hostb registers which I need as well. > | > >>> > | > >>> The only thing I see is: Attach two drivers -- one as child of acpi > | > >>> and another as child of hostb and let them communicate somehow (no > | > >>> idea how to do this). > | > >>> > | > >>> I have also done crazy things like searching for acpi0 and trying > | > >>> to bus_alloc_resource() the memory I am interested in but this also > | > >>> failed. > | > >>> > | > >>> Or is it possible to free(!) somehow the address space from acpi0 > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > | > >>> > | > >> > | > >> You can probably make two drivers in one which cooperate to > | > >> allow access to both sets of resources. > | > > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of > | > > acpi > | > > and another as child of hostb... > | > > > | > > And that's similar to Rui Paulo's suggestion a while ago: > | > > > | > >> You'll probably need to create a fake ACPI child driver to access it. > | > >> > | > >> Create your identify routine with something like: > | > >> > | > >> static void mydriver_identify(driver_t *driver, device_t parent) > | > >> { > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && > | > >> mydriver_match(parent)) > | > >> device_add_child(parent, "mydriver", -1); > | > >> } > | > >> > | > >> mydriver_match() should check if you were given the acpi0 device. > | > > > | > > But in order to attach to acpi0, I need to say > | > > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > | > > NULL ); > | > > > | > > instead of > | > > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > | > > NULL ); > | > > > | > > This way I could attach to acpi but not to hostb anymore.... > | > > > | > > I have searched the net for solutions, I have read newbus-draft.txt > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > | > > of these my driver is working on other mainboards where it doesn't > | > > have to access foreign memory) but didn't find anything. > | > > | > I'm out of ideas. > | > John, do you know if this is a newbus limitation or if it can be > | > worked around ? > | > | I assume it is possible somehow, I am just too stupid (it is the first > | driver I wrote). John, for easy reference, here is my initial message: > | > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > | > | Please remember all, that I need the access to the acpi0 memory location > | only for a few reads during probing/attaching, not later. > | > | I have also read somewhere that, when resources are allocated, the > | system "walks up" the device tree until it finds the resource. Since > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > | should work but it doesn't.. > > FWIW, you might look at ipmi(4) especially in some early states since > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > figure out the best way to attach. Also it had various front ends. > If I recall correctly, I did a find for a driver (ie. acpi) then > select the first instance. Once you get that handle then you can > request device resources from it, get the info you need then release > that stuff. However, you won't get the module auto-loading part > that you would get if you created a module that depended on both. > That might get you enough of a hint. Also there are some generic > stuff to read various memory bits like SMBIOS areas etc. This is > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > If you have a specific question, about why the driver did something > I should recall that. The ipmi(4) driver is in fairly clean. There > is some improvements I still need to do on probe/attachment that > causes a bogus ipmi1 at times. Thanks a lot for this interesting information. I see, things are more complicated than I thought. There is no easy way having a quick glance at "foreign" memory during probing. Now I have to figure out how to get the order of probing/attaching done. One thing I could do is: 1. attach mydriver_ACPI to acpi0 2. probe mydriver under hostb0, check if we need access to sysresources from acpi0 (depends on the chipset found). If no, goto 5. 3. ask mydriver_ACPI about stuff I want to know (HOW?) 4. tell mydriver to detach from acpi0 (HOW?) 5. attach mydriver to hostb0 and do my work What I would like more is something like: 1. probe mydriver under hostb0, check if we need access to sysresources from acpi0 (depends on the chipset found). If no, goto 3. 2. ask mydriver_ACPI to attach to acpi0, give me the info I want, detach mydriver_ACPI (HOW?) 3. attach mydriver to hostb0 and do my work Thanks, -Andre From ap00 at mail.ru Thu Jul 23 07:41:03 2009 From: ap00 at mail.ru (Anthony Pankov) Date: Thu Jul 23 07:41:10 2009 Subject: SGID/SUID on scripts In-Reply-To: <4A679A6B.70905@elischer.org> References: <19939654343.20090722214221@mail.ru> <4A679A6B.70905@elischer.org> Message-ID: <10490103187.20090723114310@mail.ru> Thursday, July 23, 2009, 3:02:03 AM, Julian Elischer wrote: JE> google SUID script security Preface: There is a file: rwxr-sr-x some:powerg dothething Run it: ./dothething Make shure that process egid isn't powerg. Resume: I'm too dumb to ask google "SUID script security" with this preface. As a result: May be somebody will correct chmod manual page, my poor english have endowed me with inablity to do this. >> >> And no mention in chmod(1,2) manual. >> >> >> -- Best regards, Anthony mailto:ap00@mail.ru From j.mckeown at ru.ac.za Thu Jul 23 08:18:05 2009 From: j.mckeown at ru.ac.za (Jonathan McKeown) Date: Thu Jul 23 08:18:12 2009 Subject: SGID/SUID on scripts In-Reply-To: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> Message-ID: <200907231018.02032.j.mckeown@ru.ac.za> On Thursday 23 July 2009 07:00:58 perryh@pluto.rain.com wrote: > DarkSoul wrote: > > Anthony Pankov wrote: > > > SGID/SUID bits don't work with shell scripts, do they? > > > > They don't. [snip description of race condition] > In principle, it should be possible to fix this exposure by > improving the interface between execve() and the interpreter: > > The execve() syscall already has the script file open to read the > shebang line. Leave it open, and ensure that the interpreter > receives the open descriptor as fd#3 just as 0, 1, and 2 are already > used for stdin, stdout, and stderr. An interpreter supporting this > approach would check whether stdscr (fd#3) is already open, and if > so read from it instead of open()ing the script file. This should > ensure that the script which gets executed is the same inode on > which execve() saw the SGID/SUID bits set, even if the filesystem > has been changed by the time the interpreter has gotten started. > It would be the responsibility of whomever decided to set the > SGID/SUID bits on a particular script to ensure that the interpreter > involved supports the mechanism. > > I vaguely recall having seen a similar (or even identical) approach > suggested some years ago. It may even have been implemented in some > variant of Un*x. It's mentioned in the perlsec page of perl's documentation (installed as a manpage on FreeBSD), under Security Bugs, which describes the race condition, and the same fix (keeping the script open and passing /dev/fd/3 rather than closing it and passing the filename). It goes on to say: > Most modern releases of SysVr4 and BSD 4.4 use this approach to avoid the > kernel race condition. Although it would appear not to apply to FreeBSD. Jonathan From jhb at freebsd.org Thu Jul 23 12:45:30 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jul 23 12:46:09 2009 Subject: checking number of parallel ports installed and their port adresses In-Reply-To: References: Message-ID: <200907230833.43021.jhb@freebsd.org> On Wednesday 22 July 2009 3:31:54 pm Alexander Best wrote: > the ppi manual states that using ioctl with /dev/ppi is extremely slow. i need > the parallel port to be really fast. i need to communicate with a device that > uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full ISA bus > speed to be able to push/pull data to/from the parallel port without any > delays. timing is really critical. if there's a lot of work to do for the > scheduler and the io calls get queued too long the transfer will fail. The overhead of ppi is probably in the noise on a modern CPU. I think you should be fine with just using ppi(4). > actually i meant: how can i check the available parallel ports from within my > app? is there a syscall i can use or something like that? You can look for ppcX devices perhaps. The easiest way might be to enable ppi and look for /dev/ppiX devices in /dev. -- John Baldwin From jhb at freebsd.org Thu Jul 23 12:45:31 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jul 23 12:46:10 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <20090723060835.GB62628@curry.mchp.siemens.de> References: <20090718133938.GA7802@curry.mchp.siemens.de> <200907221648.n6MGmu58035040@ambrisko.com> <20090723060835.GB62628@curry.mchp.siemens.de> Message-ID: <200907230835.50814.jhb@freebsd.org> On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > > Andre Albsmeier writes: > > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > > | > > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > > | > >> Andre Albsmeier wrote: > > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > > | > >>> > > | > >>> Since my driver is a child of hostb0, I have no idea of how to > > | > >>> access > > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > > | > >>> > > | > >> ... > > | > >>> > > | > >>> Earlier, I was given the hint to attach as a child of acpi (see the > > | > >>> old mail attached below) but in this case I didn't have access to > > | > >>> the > > | > >>> hostb registers which I need as well. > > | > >>> > > | > >>> The only thing I see is: Attach two drivers -- one as child of acpi > > | > >>> and another as child of hostb and let them communicate somehow (no > > | > >>> idea how to do this). > > | > >>> > > | > >>> I have also done crazy things like searching for acpi0 and trying > > | > >>> to bus_alloc_resource() the memory I am interested in but this also > > | > >>> failed. > > | > >>> > > | > >>> Or is it possible to free(!) somehow the address space from acpi0 > > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > > | > >>> > > | > >> > > | > >> You can probably make two drivers in one which cooperate to > > | > >> allow access to both sets of resources. > > | > > > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of > > | > > acpi > > | > > and another as child of hostb... > > | > > > > | > > And that's similar to Rui Paulo's suggestion a while ago: > > | > > > > | > >> You'll probably need to create a fake ACPI child driver to access it. > > | > >> > > | > >> Create your identify routine with something like: > > | > >> > > | > >> static void mydriver_identify(driver_t *driver, device_t parent) > > | > >> { > > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && > > | > >> mydriver_match(parent)) > > | > >> device_add_child(parent, "mydriver", -1); > > | > >> } > > | > >> > > | > >> mydriver_match() should check if you were given the acpi0 device. > > | > > > > | > > But in order to attach to acpi0, I need to say > > | > > > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > > | > > NULL ); > > | > > > > | > > instead of > > | > > > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > > | > > NULL ); > > | > > > > | > > This way I could attach to acpi but not to hostb anymore.... > > | > > > > | > > I have searched the net for solutions, I have read newbus-draft.txt > > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > > | > > of these my driver is working on other mainboards where it doesn't > > | > > have to access foreign memory) but didn't find anything. > > | > > > | > I'm out of ideas. > > | > John, do you know if this is a newbus limitation or if it can be > > | > worked around ? > > | > > | I assume it is possible somehow, I am just too stupid (it is the first > > | driver I wrote). John, for easy reference, here is my initial message: > > | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > > | > > | Please remember all, that I need the access to the acpi0 memory location > > | only for a few reads during probing/attaching, not later. > > | > > | I have also read somewhere that, when resources are allocated, the > > | system "walks up" the device tree until it finds the resource. Since > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > > | should work but it doesn't.. > > > > FWIW, you might look at ipmi(4) especially in some early states since > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > > figure out the best way to attach. Also it had various front ends. > > If I recall correctly, I did a find for a driver (ie. acpi) then > > select the first instance. Once you get that handle then you can > > request device resources from it, get the info you need then release > > that stuff. However, you won't get the module auto-loading part > > that you would get if you created a module that depended on both. > > That might get you enough of a hint. Also there are some generic > > stuff to read various memory bits like SMBIOS areas etc. This is > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > > If you have a specific question, about why the driver did something > > I should recall that. The ipmi(4) driver is in fairly clean. There > > is some improvements I still need to do on probe/attachment that > > causes a bogus ipmi1 at times. > > Thanks a lot for this interesting information. I see, things are more > complicated than I thought. There is no easy way having a quick glance > at "foreign" memory during probing. Now I have to figure out how to get > the order of probing/attaching done. One thing I could do is: > > 1. attach mydriver_ACPI to acpi0 > > 2. probe mydriver under hostb0, check if we need access to > sysresources from acpi0 (depends on the chipset found). > If no, goto 5. > > 3. ask mydriver_ACPI about stuff I want to know (HOW?) > > 4. tell mydriver to detach from acpi0 (HOW?) > > 5. attach mydriver to hostb0 and do my work > > What I would like more is something like: > > 1. probe mydriver under hostb0, check if we need access to > sysresources from acpi0 (depends on the chipset found). > If no, goto 3. > > 2. ask mydriver_ACPI to attach to acpi0, give me the info > I want, detach mydriver_ACPI (HOW?) > > 3. attach mydriver to hostb0 and do my work Did you try doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your driver that is a child of hostb0? -- John Baldwin From ivoras at freebsd.org Thu Jul 23 16:16:16 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jul 23 16:16:25 2009 Subject: SGID/SUID on scripts In-Reply-To: <4A6795E7.7020700@darkbsd.org> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> Message-ID: DarkSoul wrote: > Anthony Pankov wrote: >> SGID/SUID bits don't work with shell scripts, do they? >> >> And no mention in chmod(1,2) manual. > > They don't. > > One reason for this, is that if they were applied, the following would > occur : > - execve() syscall reads your script's shebang line, and the script > interpreter is executed, receiving the specified arguments along with > the script name. > - The interpreter then open()s the script file to read it, and run the code. > > The problem you then are faced with, is that you have a time frame > defined by the moment between the aforementioned execve() and open(), > during which it could be possible to unlink/move/whatever the shell > script the interpreter is going to open. > > You guess where this is going, you have no absolute way of guaranteeing > you are executing the file you initially planned on opening because > execution/opening/reading is not, and can't be done atomically for shell > scripts. Hmm... Presumingly, the biggest concern is with scripts owned by root. Who can unlink, move or change the script? The owner and his group can change it; the directory owner can unlink it. It looks like the targetted problem is if a root creates a script in a user-owned directory and then makes it suid. It looks more like a PEBKAC then a system problem - is it really so serious there is no sysctl to disable the check? From ambrisko at ambrisko.com Thu Jul 23 16:19:54 2009 From: ambrisko at ambrisko.com (Doug Ambrisko) Date: Thu Jul 23 16:20:01 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <200907230835.50814.jhb@freebsd.org> Message-ID: <200907231425.n6NEPeRH026492@ambrisko.com> John Baldwin writes: | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: | > > Andre Albsmeier writes: | > > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: | > > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: | > > | > | > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: | > > | > >> Andre Albsmeier wrote: | > > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] | > > | > >>> | > > | > >>> Since my driver is a child of hostb0, I have no idea of how to | > > | > >>> access | > > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: | > > | > >>> | > > | > >> ... | > > | > >>> | > > | > >>> Earlier, I was given the hint to attach as a child of acpi (see | the | > > | > >>> old mail attached below) but in this case I didn't have access to | > > | > >>> the | > > | > >>> hostb registers which I need as well. | > > | > >>> | > > | > >>> The only thing I see is: Attach two drivers -- one as child of | acpi | > > | > >>> and another as child of hostb and let them communicate somehow (no | > > | > >>> idea how to do this). | > > | > >>> | > > | > >>> I have also done crazy things like searching for acpi0 and trying | > > | > >>> to bus_alloc_resource() the memory I am interested in but this | also | > > | > >>> failed. | > > | > >>> | > > | > >>> Or is it possible to free(!) somehow the address space from acpi0 | > > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? | > > | > >>> | > > | > >> | > > | > >> You can probably make two drivers in one which cooperate to | > > | > >> allow access to both sets of resources. | > > | > > | > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of | > > | > > acpi | > > | > > and another as child of hostb... | > > | > > | > > | > > And that's similar to Rui Paulo's suggestion a while ago: | > > | > > | > > | > >> You'll probably need to create a fake ACPI child driver to access | it. | > > | > >> | > > | > >> Create your identify routine with something like: | > > | > >> | > > | > >> static void mydriver_identify(driver_t *driver, device_t parent) | > > | > >> { | > > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && | > > | > >> mydriver_match(parent)) | > > | > >> device_add_child(parent, "mydriver", -1); | > > | > >> } | > > | > >> | > > | > >> mydriver_match() should check if you were given the acpi0 device. | > > | > > | > > | > > But in order to attach to acpi0, I need to say | > > | > > | > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, | > > | > > NULL ); | > > | > > | > > | > > instead of | > > | > > | > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, | > > | > > NULL ); | > > | > > | > > | > > This way I could attach to acpi but not to hostb anymore.... | > > | > > | > > | > > I have searched the net for solutions, I have read newbus-draft.txt | > > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all | > > | > > of these my driver is working on other mainboards where it doesn't | > > | > > have to access foreign memory) but didn't find anything. | > > | > | > > | > I'm out of ideas. | > > | > John, do you know if this is a newbus limitation or if it can be | > > | > worked around ? | > > | | > > | I assume it is possible somehow, I am just too stupid (it is the first | > > | driver I wrote). John, for easy reference, here is my initial message: | > > | | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html | > > | | > > | Please remember all, that I need the access to the acpi0 memory location | > > | only for a few reads during probing/attaching, not later. | > > | | > > | I have also read somewhere that, when resources are allocated, the | > > | system "walks up" the device tree until it finds the resource. Since | > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it | > > | should work but it doesn't.. | > > | > > FWIW, you might look at ipmi(4) especially in some early states since | > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to | > > figure out the best way to attach. Also it had various front ends. | > > If I recall correctly, I did a find for a driver (ie. acpi) then | > > select the first instance. Once you get that handle then you can | > > request device resources from it, get the info you need then release | > > that stuff. However, you won't get the module auto-loading part | > > that you would get if you created a module that depended on both. | > > That might get you enough of a hint. Also there are some generic | > > stuff to read various memory bits like SMBIOS areas etc. This is | > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. | > > If you have a specific question, about why the driver did something | > > I should recall that. The ipmi(4) driver is in fairly clean. There | > > is some improvements I still need to do on probe/attachment that | > > causes a bogus ipmi1 at times. | > | > Thanks a lot for this interesting information. I see, things are more | > complicated than I thought. There is no easy way having a quick glance | > at "foreign" memory during probing. Now I have to figure out how to get | > the order of probing/attaching done. One thing I could do is: | > | > 1. attach mydriver_ACPI to acpi0 | > | > 2. probe mydriver under hostb0, check if we need access to | > sysresources from acpi0 (depends on the chipset found). | > If no, goto 5. | > | > 3. ask mydriver_ACPI about stuff I want to know (HOW?) | > | > 4. tell mydriver to detach from acpi0 (HOW?) | > | > 5. attach mydriver to hostb0 and do my work | > | > What I would like more is something like: | > | > 1. probe mydriver under hostb0, check if we need access to | > sysresources from acpi0 (depends on the chipset found). | > If no, goto 3. | > | > 2. ask mydriver_ACPI to attach to acpi0, give me the info | > I want, detach mydriver_ACPI (HOW?) | > | > 3. attach mydriver to hostb0 and do my work | | Did you try | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your | driver that is a child of hostb0? That should basically work since almost everything is a child of acpi. However, the depth could change so running through the device_get_parent and then checking the name might be good. BTW, there is an example in sys/compat/linsysfs/linsysfs.c in which I run the entire bus tree via linsysfs_run_bus which is recursive and started from linsysfs_init. As John and I say, you don't need to "attach" to acpi just allocate what you need, access it, then release it. If you need to hold on it then it becomes more involved. Since you never attach then you don't need to dettach just release the resources you grabbed ( ie. bus_release_resource what you bus_alloc_resource). Doug A. From perryh at pluto.rain.com Thu Jul 23 17:49:28 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Thu Jul 23 17:49:35 2009 Subject: SGID/SUID on scripts In-Reply-To: References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> Message-ID: <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> Ivan Voras wrote: > Presumingly, the biggest concern is with scripts owned by root. > Who can unlink, move or change the script? The owner and his > group can change it; the directory owner can unlink it ... Anyone can make a link to such a script in, say, /tmp and then mess with the link :( From jhb at freebsd.org Thu Jul 23 17:52:28 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jul 23 17:52:54 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <200907231425.n6NEPeRH026492@ambrisko.com> References: <200907231425.n6NEPeRH026492@ambrisko.com> Message-ID: <200907231346.42168.jhb@freebsd.org> On Thursday 23 July 2009 10:25:40 am Doug Ambrisko wrote: > John Baldwin writes: > | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: > | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > | > > Andre Albsmeier writes: > | > > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > | > > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > | > > | > > | > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > | > > | > >> Andre Albsmeier wrote: > | > > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > | > > | > >>> > | > > | > >>> Since my driver is a child of hostb0, I have no idea of how to > | > > | > >>> access > | > > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > | > > | > >>> > | > > | > >> ... > | > > | > >>> > | > > | > >>> Earlier, I was given the hint to attach as a child of acpi (see > | the > | > > | > >>> old mail attached below) but in this case I didn't have access to > | > > | > >>> the > | > > | > >>> hostb registers which I need as well. > | > > | > >>> > | > > | > >>> The only thing I see is: Attach two drivers -- one as child of > | acpi > | > > | > >>> and another as child of hostb and let them communicate somehow (no > | > > | > >>> idea how to do this). > | > > | > >>> > | > > | > >>> I have also done crazy things like searching for acpi0 and trying > | > > | > >>> to bus_alloc_resource() the memory I am interested in but this > | also > | > > | > >>> failed. > | > > | > >>> > | > > | > >>> Or is it possible to free(!) somehow the address space from acpi0 > | > > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > | > > | > >>> > | > > | > >> > | > > | > >> You can probably make two drivers in one which cooperate to > | > > | > >> allow access to both sets of resources. > | > > | > > > | > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of > | > > | > > acpi > | > > | > > and another as child of hostb... > | > > | > > > | > > | > > And that's similar to Rui Paulo's suggestion a while ago: > | > > | > > > | > > | > >> You'll probably need to create a fake ACPI child driver to access > | it. > | > > | > >> > | > > | > >> Create your identify routine with something like: > | > > | > >> > | > > | > >> static void mydriver_identify(driver_t *driver, device_t parent) > | > > | > >> { > | > > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && > | > > | > >> mydriver_match(parent)) > | > > | > >> device_add_child(parent, "mydriver", -1); > | > > | > >> } > | > > | > >> > | > > | > >> mydriver_match() should check if you were given the acpi0 device. > | > > | > > > | > > | > > But in order to attach to acpi0, I need to say > | > > | > > > | > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > | > > | > > NULL ); > | > > | > > > | > > | > > instead of > | > > | > > > | > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > | > > | > > NULL ); > | > > | > > > | > > | > > This way I could attach to acpi but not to hostb anymore.... > | > > | > > > | > > | > > I have searched the net for solutions, I have read newbus-draft.txt > | > > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > | > > | > > of these my driver is working on other mainboards where it doesn't > | > > | > > have to access foreign memory) but didn't find anything. > | > > | > > | > > | > I'm out of ideas. > | > > | > John, do you know if this is a newbus limitation or if it can be > | > > | > worked around ? > | > > | > | > > | I assume it is possible somehow, I am just too stupid (it is the first > | > > | driver I wrote). John, for easy reference, here is my initial message: > | > > | > | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > | > > | > | > > | Please remember all, that I need the access to the acpi0 memory location > | > > | only for a few reads during probing/attaching, not later. > | > > | > | > > | I have also read somewhere that, when resources are allocated, the > | > > | system "walks up" the device tree until it finds the resource. Since > | > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > | > > | should work but it doesn't.. > | > > > | > > FWIW, you might look at ipmi(4) especially in some early states since > | > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > | > > figure out the best way to attach. Also it had various front ends. > | > > If I recall correctly, I did a find for a driver (ie. acpi) then > | > > select the first instance. Once you get that handle then you can > | > > request device resources from it, get the info you need then release > | > > that stuff. However, you won't get the module auto-loading part > | > > that you would get if you created a module that depended on both. > | > > That might get you enough of a hint. Also there are some generic > | > > stuff to read various memory bits like SMBIOS areas etc. This is > | > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > | > > If you have a specific question, about why the driver did something > | > > I should recall that. The ipmi(4) driver is in fairly clean. There > | > > is some improvements I still need to do on probe/attachment that > | > > causes a bogus ipmi1 at times. > | > > | > Thanks a lot for this interesting information. I see, things are more > | > complicated than I thought. There is no easy way having a quick glance > | > at "foreign" memory during probing. Now I have to figure out how to get > | > the order of probing/attaching done. One thing I could do is: > | > > | > 1. attach mydriver_ACPI to acpi0 > | > > | > 2. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 5. > | > > | > 3. ask mydriver_ACPI about stuff I want to know (HOW?) > | > > | > 4. tell mydriver to detach from acpi0 (HOW?) > | > > | > 5. attach mydriver to hostb0 and do my work > | > > | > What I would like more is something like: > | > > | > 1. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 3. > | > > | > 2. ask mydriver_ACPI to attach to acpi0, give me the info > | > I want, detach mydriver_ACPI (HOW?) > | > > | > 3. attach mydriver to hostb0 and do my work > | > | Did you try > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your > | driver that is a child of hostb0? > > That should basically work since almost everything is a child of acpi. > However, the depth could change so running through the device_get_parent > and then checking the name might be good. In this case hostbX's grandparent is always pciX (usually pci0) and the PCI bus driver just passes through requests that come from grandchildren w/o trying to match the rid to a BAR. > As John and I say, you don't need to "attach" to acpi just allocate > what you need, access it, then release it. If you need to hold on > it then it becomes more involved. Since you never attach then you > don't need to dettach just release the resources you grabbed ( > ie. bus_release_resource what you bus_alloc_resource). This is true. However, to attach to acpi you generally need some device_t device to attach to. You could create a fictitious device via an identify routine, but I think that would be a far bigger hack than just doing the device_get_parent() bit in your hostbX driver's probe routine. -- John Baldwin From Andre.Albsmeier at siemens.com Thu Jul 23 17:53:56 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Thu Jul 23 17:54:04 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <200907231425.n6NEPeRH026492@ambrisko.com> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> Message-ID: <20090723175351.GA70584@curry.mchp.siemens.de> John, apparently you sent me an email (thanks a lot) which I never received (we have to blame our company's spam filters which I do not control). I'll comment on it here in my reply to Doug... On Thu, 23-Jul-2009 at 07:25:40 -0700, Doug Ambrisko wrote: > John Baldwin writes: > | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: > | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > | > > Andre Albsmeier writes: > | > > | > stripping some elder stuff > | > > | > | > > | I assume it is possible somehow, I am just too stupid (it is the first > | > > | driver I wrote). John, for easy reference, here is my initial message: > | > > | > | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > | > > | > | > > | Please remember all, that I need the access to the acpi0 memory location > | > > | only for a few reads during probing/attaching, not later. > | > > | > | > > | I have also read somewhere that, when resources are allocated, the > | > > | system "walks up" the device tree until it finds the resource. Since > | > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > | > > | should work but it doesn't.. > | > > > | > > FWIW, you might look at ipmi(4) especially in some early states since > | > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > | > > figure out the best way to attach. Also it had various front ends. > | > > If I recall correctly, I did a find for a driver (ie. acpi) then > | > > select the first instance. Once you get that handle then you can > | > > request device resources from it, get the info you need then release > | > > that stuff. However, you won't get the module auto-loading part > | > > that you would get if you created a module that depended on both. > | > > That might get you enough of a hint. Also there are some generic > | > > stuff to read various memory bits like SMBIOS areas etc. This is > | > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > | > > If you have a specific question, about why the driver did something > | > > I should recall that. The ipmi(4) driver is in fairly clean. There > | > > is some improvements I still need to do on probe/attachment that > | > > causes a bogus ipmi1 at times. > | > > | > Thanks a lot for this interesting information. I see, things are more > | > complicated than I thought. There is no easy way having a quick glance > | > at "foreign" memory during probing. Now I have to figure out how to get > | > the order of probing/attaching done. One thing I could do is: > | > > | > 1. attach mydriver_ACPI to acpi0 > | > > | > 2. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 5. > | > > | > 3. ask mydriver_ACPI about stuff I want to know (HOW?) > | > > | > 4. tell mydriver to detach from acpi0 (HOW?) > | > > | > 5. attach mydriver to hostb0 and do my work > | > > | > What I would like more is something like: > | > > | > 1. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 3. > | > > | > 2. ask mydriver_ACPI to attach to acpi0, give me the info > | > I want, detach mydriver_ACPI (HOW?) > | > > | > 3. attach mydriver to hostb0 and do my work > | > | Did you try > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your > | driver that is a child of hostb0? I tried this, well, something similar: I had to do 4 times device_get_parent() to end up at acpi0: mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 > > That should basically work since almost everything is a child of acpi. Thats what I hoped indeed. It would be a lot simpler than working with two drivers which have to communicate with each other. > However, the depth could change so running through the device_get_parent > and then checking the name might be good. I thought the same so I decided to lookup the acpi devclass and then acpi0 from there. To be sure, I compared the resulting pointers of acpi0 with the one found after the four device_get_parent(). They were the same. > > BTW, there is an example in sys/compat/linsysfs/linsysfs.c > in which I run the entire bus tree via linsysfs_run_bus which is > recursive and started from linsysfs_init. > > As John and I say, you don't need to "attach" to acpi just allocate > what you need, access it, then release it. If you need to hold on > it then it becomes more involved. Since you never attach then you > don't need to dettach just release the resources you grabbed ( > ie. bus_release_resource what you bus_alloc_resource). Well, then I still must be doing something wrong. I have attached my driver skeleton which does the following: 1. device_identify() which does a device_add_child() if needed 2. device_probe() which just tries to bus_alloc_resource() a SYS_RES_MEMORY resource from acpi0. If it works (which never does :-(), call bus_release_resource(). device_probe() always returns ENXIO so the whole driver never attaches. Especially in device_probe() I do: 1. Search for acpi0. 2. List the resources of acpi0. I compared the list to my "devinfo -r" output and they are the same. 3. Take the first SYS_RES_MEMORY resource from the list in 2. and try to bus_alloc_resource() it. This never succeds. Maybe you find the bug in there, I run out of ideas. It's not much of code, most of it are device_printfs for debugging... I have also attached the Makefile in case someone wants to kldload it on his machine. I would be very interested if it worked there. Thanks to you and John, of course. -Andre -------------- next part -------------- KMOD = eccmon SRCS = eccmon.c device_if.h bus_if.h pci_if.h NO_MAN = 1 CFLAGS+=-DDEVEL .include From ivoras at freebsd.org Thu Jul 23 18:40:59 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jul 23 18:41:06 2009 Subject: SGID/SUID on scripts In-Reply-To: <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> Message-ID: <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> 2009/7/23 : > Ivan Voras wrote: >> Presumingly, the biggest concern is with scripts owned by root. >> Who can unlink, move or change the script? The owner and his >> group can change it; the directory owner can unlink it ... > > Anyone can make a link to such a script in, say, /tmp and then > mess with the link :( You mean setuid a soft link? That's allowed? -- f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A== From lgusenet at be-well.ilk.org Thu Jul 23 18:55:35 2009 From: lgusenet at be-well.ilk.org (Lowell Gilbert) Date: Thu Jul 23 19:00:51 2009 Subject: SGID/SUID on scripts In-Reply-To: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> (perryh@pluto.rain.com's message of "Wed\, 22 Jul 2009 22\:00\:58 -0700") References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> Message-ID: <44my6v8d97.fsf@be-well.ilk.org> perryh@pluto.rain.com writes: > DarkSoul wrote: >> Anthony Pankov wrote: >> > SGID/SUID bits don't work with shell scripts, do they? >> >> They don't. >> >> ... if they were applied, the following would occur : >> - execve() syscall reads your script's shebang line, and >> the script interpreter is executed, receiving the specified >> arguments along with the script name. >> - The interpreter then open()s the script file to read it, >> and run the code. >> >> The problem you then are faced with, is that you have a time >> frame defined by the moment between the aforementioned execve() >> and open(), during which it could be possible to unlink/move/ >> whatever the shell script the interpreter is going to open. >> >> You guess where this is going, you have no absolute way of >> guaranteeing you are executing the file you initially planned >> on opening because execution/opening/reading is not, and can't >> be done atomically for shell scripts. > > In principle, it should be possible to fix this exposure by > improving the interface between execve() and the interpreter: > > The execve() syscall already has the script file open to read the > shebang line. Leave it open, and ensure that the interpreter > receives the open descriptor as fd#3 just as 0, 1, and 2 are already > used for stdin, stdout, and stderr. An interpreter supporting this > approach would check whether stdscr (fd#3) is already open, and if > so read from it instead of open()ing the script file. This should > ensure that the script which gets executed is the same inode on > which execve() saw the SGID/SUID bits set, even if the filesystem > has been changed by the time the interpreter has gotten started. > It would be the responsibility of whomever decided to set the > SGID/SUID bits on a particular script to ensure that the interpreter > involved supports the mechanism. > > I vaguely recall having seen a similar (or even identical) approach > suggested some years ago. It may even have been implemented in some > variant of Un*x. That's clever, but how would it work in practice, while common shells and scripting languages may not implement their side of it? From jhb at freebsd.org Thu Jul 23 20:06:12 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jul 23 20:06:19 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <20090723175351.GA70584@curry.mchp.siemens.de> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> <20090723175351.GA70584@curry.mchp.siemens.de> Message-ID: <200907231606.11904.jhb@freebsd.org> On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote: > John, apparently you sent me an email (thanks a lot) which I never > received (we have to blame our company's spam filters which I do > not control). I'll comment on it here in my reply to Doug... Yes, I saw the bounces. Hopefully you see the list version of this. > > | Did you try > > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your > > | driver that is a child of hostb0? > > I tried this, well, something similar: I had to do 4 times > device_get_parent() to end up at acpi0: > > mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 You don't actually need to do that. pci0 will pass the request up to acpi0 eventually. You just need to ask pci0 to allocate it for you and it will see you are not a direct child and take the 'passthrough' case here: struct resource * pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { ... if (device_get_parent(child) != dev) return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, type, rid, start, end, count, flags)); ... } Rather than trying to allocate the whole chunk of the ACPI resource, I would just do a specific allocation like so: rid = 0; res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), dev, SYS_RES_MEMORY, &rid, , , , RF_ACTIVE); -- John Baldwin From stephane.lapie at darkbsd.org Thu Jul 23 23:12:07 2009 From: stephane.lapie at darkbsd.org (Stephane LAPIE) Date: Thu Jul 23 23:12:14 2009 Subject: SGID/SUID on scripts In-Reply-To: <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> Message-ID: <4A68EA4A.8070102@darkbsd.org> Ivan Voras wrote: > 2009/7/23 : >> Ivan Voras wrote: >>> Presumingly, the biggest concern is with scripts owned by root. >>> Who can unlink, move or change the script? The owner and his >>> group can change it; the directory owner can unlink it ... >> Anyone can make a link to such a script in, say, /tmp and then >> mess with the link :( Either way, allowing SUID on scripts without proper guarantees you actually run what you WANT to run, would mean that you can basically execute "whatever code you are able to slip in there" using someone else's credentials, even if not root. You could be able to modify scripts belonging to your own group, while not being able to execute them with the owner user. The point is : "ID/credential usurpation", even if not actual meaningful (on a system-level) "privilege escalation" per se can be a grave problem enough, especially in corporate environments. Therefore any implementation allowing for this behavior should not be accepted, imho. -- Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090723/b83e2b7d/signature.pgp From j.mckeown at ru.ac.za Fri Jul 24 07:02:12 2009 From: j.mckeown at ru.ac.za (Jonathan McKeown) Date: Fri Jul 24 07:02:18 2009 Subject: SGID/SUID on scripts In-Reply-To: <44my6v8d97.fsf@be-well.ilk.org> References: <19939654343.20090722214221@mail.ru> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> <44my6v8d97.fsf@be-well.ilk.org> Message-ID: <200907240902.09609.j.mckeown@ru.ac.za> On Thursday 23 July 2009 20:28:52 Lowell Gilbert wrote: > perryh@pluto.rain.com writes: [snip description of shell opening a script, finding a #! line and passing a file descriptor for the opened script to the intended interpreter in /dev/fd/, to avoid a race condition where the shell opens the script, reads the #! line, closes it and hands off the filename to the intended interpreter to reopen what may now be a different file] > > I vaguely recall having seen a similar (or even identical) approach > > suggested some years ago. It may even have been implemented in some > > variant of Un*x. > > That's clever, but how would it work in practice, while common shells > and scripting languages may not implement their side of it? http://www.in-ulm.de/~mascheck/various/shebang/ claims that it's been implemented, in exactly the way described, in Solaris, OpenBSD and NetBSD (albeit as a kernel compile-time option in the latter two). (It's apparently also in IRIX and UnixWare). Given OpenBSD's admirable paranoia about security (hey, I'm a sysadmin: I never ask myself if I'm being paranoid, but if I'm being paranoid enough!) I'd have thought they would have explored the implications fully. Certainly other stuff knows about it. As I said yesterday, Perl describes the problem in its perlsec manpage/perldoc. The perl interpreter even has a build-time option, SETUID_SCRIPTS_ARE_SECURE_NOW - and the correct setting is supposedly detected as part of configure. There may well be some problems to overcome, but this doesn't appear to be unexplored territory. Jonathan From perryh at pluto.rain.com Fri Jul 24 07:41:48 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Fri Jul 24 07:41:54 2009 Subject: SGID/SUID on scripts In-Reply-To: <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> Message-ID: <4a696257.YpRb/zYqgBw8bwVp%perryh@pluto.rain.com> Ivan Voras wrote: > 2009/7/23 : > > Ivan Voras wrote: > >> Presumingly, the biggest concern is with scripts owned by root. > >> Who can unlink, move or change the script? The owner and his > >> group can change it; the directory owner can unlink it ... > > > > Anyone can make a link to such a script in, say, /tmp and then > > mess with the link :( > > You mean setuid a soft link? That's allowed? One can certainly make a symlink that points to a setuid file. The permissions of the symlink itself don't matter. IIRC the original demonstration that this exposure was real and not just theoretical involved making -- and subsequently messing with -- a hard link in /tmp to a setuid script in /bin, /tmp and /bin both being on the root FS. (This was before machines commonly had enough RAM for tmpfs to be practical, and may have been before symlinks even existed.) Granted a case can be made for making /tmp a separate FS in any event, but of course it would have worked just as well to make a link in /usr/tmp to a setuid script in /usr/bin, etc. The only way to avoid the exposure would have been to ensure that no possible attacker would have write permission to any directory on the same FS as a setuid script to which the attacker had execute permission -- not the easiest thing to keep track of on an ongoing basis. With the existence of symlinks I suspect even that would no longer help. From jeremie at le-hen.org Fri Jul 24 07:54:30 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri Jul 24 07:54:37 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090509121313.GA58540@hoeg.nl> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> Message-ID: <20090724073451.GH54986@felucia.tataz.chchile.org> Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > We probably could. I think I discussed this with Robert Watson some time > ago and we could use things like ELF hints. But still, that doesn't > prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From kostikbel at gmail.com Fri Jul 24 08:19:12 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 24 08:19:19 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724073451.GH54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> Message-ID: <20090724081842.GF55190@deviant.kiev.zoral.com.ua> On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > Hi Ed, > > Sorry for the late reply. > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > We probably could. I think I discussed this with Robert Watson some time > > ago and we could use things like ELF hints. But still, that doesn't > > prevent us from reaching this limitation later on. > > Can you elaborate a little? Are you talking about elf-hints.h? > I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090724/9a7ad0bc/attachment.pgp From alexbestms at math.uni-muenster.de Fri Jul 24 10:42:38 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Jul 24 10:42:45 2009 Subject: checking number of parallel ports installed and their port adresses In-Reply-To: <200907230833.43021.jhb@freebsd.org> Message-ID: thanks for the hint. if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i was very surprised about the results since you said the overhead wouldn't be that big. uploading a 256 kbyte file i got the following results: using ppi: 17.120 seconds using in/out opcodes: 8.001 seconds so i think i'll rather stick to my old inline assembly code even if it can't be considered nice programming style, but the ppi overhead isn't something i can cope with in my app. cheers. alex John Baldwin schrieb am 2009-07-23: > On Wednesday 22 July 2009 3:31:54 pm Alexander Best wrote: > > the ppi manual states that using ioctl with /dev/ppi is extremely > > slow. i need > > the parallel port to be really fast. i need to communicate with a > > device that > > uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full > > ISA bus > > speed to be able to push/pull data to/from the parallel port > > without any > > delays. timing is really critical. if there's a lot of work to do > > for the > > scheduler and the io calls get queued too long the transfer will > > fail. > The overhead of ppi is probably in the noise on a modern CPU. I > think you > should be fine with just using ppi(4). > > actually i meant: how can i check the available parallel ports from > > within my > > app? is there a syscall i can use or something like that? > You can look for ppcX devices perhaps. The easiest way might be to > enable > ppi and look for /dev/ppiX devices in /dev. From jeremie at le-hen.org Fri Jul 24 11:54:50 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri Jul 24 11:54:57 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724081842.GF55190@deviant.kiev.zoral.com.ua> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> Message-ID: <20090724115404.GI54986@felucia.tataz.chchile.org> On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > Hi Ed, > > > > Sorry for the late reply. > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > We probably could. I think I discussed this with Robert Watson some time > > > ago and we could use things like ELF hints. But still, that doesn't > > > prevent us from reaching this limitation later on. > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > I don't see where we can get randomness from it. > > The thing is called ELF auxillary information vector. It is used to > supply some useful information for interpreter from the kernel, > see include/machine/elf.h for AT_* entries. Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, generated at link time, that will be used to fill the canary at exec(2) time? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From ed at 80386.nl Fri Jul 24 11:56:50 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Jul 24 11:56:58 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724115404.GI54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> Message-ID: <20090724115649.GV68469@hoeg.nl> * Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > Hi Ed, > > > > > > Sorry for the late reply. > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > We probably could. I think I discussed this with Robert Watson some time > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > prevent us from reaching this limitation later on. > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > I don't see where we can get randomness from it. > > > > The thing is called ELF auxillary information vector. It is used to > > supply some useful information for interpreter from the kernel, > > see include/machine/elf.h for AT_* entries. > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > generated at link time, that will be used to fill the canary at exec(2) > time? Very short answer: yes! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090724/74e53a12/attachment.pgp From kostikbel at gmail.com Fri Jul 24 11:58:53 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 24 11:59:00 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724115404.GI54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> Message-ID: <20090724115830.GG55190@deviant.kiev.zoral.com.ua> On Fri, Jul 24, 2009 at 01:54:04PM +0200, Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > Hi Ed, > > > > > > Sorry for the late reply. > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > We probably could. I think I discussed this with Robert Watson some time > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > prevent us from reaching this limitation later on. > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > I don't see where we can get randomness from it. > > > > The thing is called ELF auxillary information vector. It is used to > > supply some useful information for interpreter from the kernel, > > see include/machine/elf.h for AT_* entries. > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > generated at link time, that will be used to fill the canary at exec(2) > time? The aux entries are not hints, and they are put on the new image stack when execve() activates the image. Aux entries has nothing to do with static link time, they are supplied to the dynamic linker (ELF interpreter). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090724/d009593b/attachment.pgp From jeremie at le-hen.org Fri Jul 24 13:10:14 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri Jul 24 13:10:22 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724115649.GV68469@hoeg.nl> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> Message-ID: <20090724130928.GJ54986@felucia.tataz.chchile.org> On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > * Jeremie Le Hen wrote: > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > Hi Ed, > > > > > > > > Sorry for the late reply. > > > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > We probably could. I think I discussed this with Robert Watson some time > > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > > prevent us from reaching this limitation later on. > > > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > I don't see where we can get randomness from it. > > > > > > The thing is called ELF auxillary information vector. It is used to > > > supply some useful information for interpreter from the kernel, > > > see include/machine/elf.h for AT_* entries. > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > generated at link time, that will be used to fill the canary at exec(2) > > time? > > Very short answer: yes! Ok thanks. But this would make stack protection useless for local attacks on suid binaries that are world-readable since the attacker could read the ELF aux vector and compute the canary. Upon each invocation, the canary would stay the same which makes the repeat-until-success attack feasible for daemons that are automatically respawned. This saves one syscall per exec(2) but reduce security for the two cases described above. In the performance test I've run with and without -fstack-protector to build world, I saw only around 1 percent penalty. I must admit this was on a UP system which wasn't loaded though. I know that the sysctl system may be redesigned in the future to allow more concurrency. Is it something that could prevent from changing the way the canary is initialized? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From ed at 80386.nl Fri Jul 24 13:49:54 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Jul 24 13:50:01 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724130928.GJ54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> Message-ID: <20090724134953.GW68469@hoeg.nl> * Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > > * Jeremie Le Hen wrote: > > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > > Hi Ed, > > > > > > > > > > Sorry for the late reply. > > > > > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > > We probably could. I think I discussed this with Robert Watson some time > > > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > > > prevent us from reaching this limitation later on. > > > > > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > > I don't see where we can get randomness from it. > > > > > > > > The thing is called ELF auxillary information vector. It is used to > > > > supply some useful information for interpreter from the kernel, > > > > see include/machine/elf.h for AT_* entries. > > > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > > generated at link time, that will be used to fill the canary at exec(2) > > > time? > > > > Very short answer: yes! > > Ok thanks. But this would make stack protection useless for local > attacks on suid binaries that are world-readable since the attacker > could read the ELF aux vector and compute the canary. Wait wait wait. It seems you were only partially right (and Kostik corrected you): We could add AT_RANDOM, but this value will be filled in by the kernel when starting the process. This means the random value is not stored in the binary. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090724/3fa46cc8/attachment.pgp From jhb at freebsd.org Fri Jul 24 14:51:56 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Jul 24 14:52:03 2009 Subject: checking number of parallel ports installed and their port adresses In-Reply-To: References: Message-ID: <200907240747.45738.jhb@freebsd.org> On Friday 24 July 2009 6:42:34 am Alexander Best wrote: > thanks for the hint. > > if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i > was very surprised about the results since you said the overhead wouldn't be > that big. > > uploading a 256 kbyte file i got the following results: > > using ppi: 17.120 seconds > using in/out opcodes: 8.001 seconds > > so i think i'll rather stick to my old inline assembly code even if it can't > be considered nice programming style, but the ppi overhead isn't something i > can cope with in my app. Hmmm, that is a bit much. Though I do suppose you are incurring a user -> kernel -> user transition for each I/O access. -- John Baldwin From alexbestms at math.uni-muenster.de Fri Jul 24 16:02:37 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Jul 24 16:02:44 2009 Subject: checking number of parallel ports installed and their port adresses In-Reply-To: <200907240747.45738.jhb@freebsd.org> Message-ID: well i'm performing a large number of port accesses since the data gets transferred bit-by-bit over a single parallel port pin with another pin acting as clock. so transfering 256 kbyte of data means i'm doing >= 256*1024*8*2 ioctls. i guess when transfering data on a nibble, byte, word or dword basis the overhead isn't that dramatic. alex John Baldwin schrieb am 2009-07-24: > On Friday 24 July 2009 6:42:34 am Alexander Best wrote: > > thanks for the hint. > > if spent a bit of time and turned the in/out opcodes to ppi ioctls. > > actually > i > > was very surprised about the results since you said the overhead > > wouldn't be > > that big. > > uploading a 256 kbyte file i got the following results: > > using ppi: 17.120 seconds > > using in/out opcodes: 8.001 seconds > > so i think i'll rather stick to my old inline assembly code even if > > it can't > > be considered nice programming style, but the ppi overhead isn't > > something i > > can cope with in my app. > Hmmm, that is a bit much. Though I do suppose you are incurring a > user -> > kernel -> user transition for each I/O access. From Andre.Albsmeier at siemens.com Fri Jul 24 16:17:46 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Fri Jul 24 16:17:53 2009 Subject: Reading acpi memory from a driver attached to hostb In-Reply-To: <200907231606.11904.jhb@freebsd.org> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> <20090723175351.GA70584@curry.mchp.siemens.de> <200907231606.11904.jhb@freebsd.org> Message-ID: <20090724161742.GA73257@curry.mchp.siemens.de> On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote: > On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote: > > John, apparently you sent me an email (thanks a lot) which I never > > received (we have to blame our company's spam filters which I do > > not control). I'll comment on it here in my reply to Doug... > > Yes, I saw the bounces. Hopefully you see the list version of this. Yes, I've been lucky this time. > > > > | Did you try > > > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in > your > > > | driver that is a child of hostb0? > > > > I tried this, well, something similar: I had to do 4 times > > device_get_parent() to end up at acpi0: > > > > mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 > > You don't actually need to do that. pci0 will pass the request up to acpi0 That's what I hoped as well. > eventually. You just need to ask pci0 to allocate it for you and it will see > you are not a direct child and take the 'passthrough' case here: > > struct resource * > pci_alloc_resource(device_t dev, device_t child, int type, int *rid, > u_long start, u_long end, u_long count, u_int flags) > { > ... > > if (device_get_parent(child) != dev) > return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, > type, rid, start, end, count, flags)); > ... > } > > Rather than trying to allocate the whole chunk of the ACPI resource, I would > just do a specific allocation like so: > > rid = 0; > res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), > dev, SYS_RES_MEMORY, &rid, , end address>, , RF_ACTIVE); OK, I have modified my driver exactly this way, but still no success. It seems my code didn't make it to the list (the attachment was stripped) so I include it inline now. Testing is quite simple, every feedback is welcome: 1. check if "devinfo -r" spits out some free "I/O memory addresses" ranges under acpi0 with at minimum 4 bytes length. 2. select one of them and assign its start address to rstart in eccmon_probe() at the line which reads now u_long rstart = 0xfed14000; (this is the address I use for testing) 3. compile, kldload and dmesg. I always get the message "bus_alloc_resource() returned NULL". Thanks, -Andre -------------------- eccmon.c start ------------------------------------- #include #include #include #include #include #include #include #include #include #include struct eccmon_softc { device_t dev; int res_set; /* flag if bus_set_resource() was used successfully */ struct resource* res; int rid; }; /**********************/ /* eccmon_probe() */ /**********************/ static int eccmon_probe( const device_t const dev ) { u_long rstart = 0xfed14000; int ret; struct resource* res; int rid = 0; device_printf( dev, "probe: started for %x:%x\n", pci_get_vendor( dev ) , pci_get_device( dev ) ); /* * try to bus_alloc_resource the resource and give it back */ if( (res = BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)), dev, SYS_RES_MEMORY, &rid, rstart, rstart+4, 4, RF_ACTIVE )) == NULL ) { device_printf( dev, "bus_alloc_resource() returned NULL\n" ); return ENXIO; } if( (ret = BUS_RELEASE_RESOURCE( device_get_parent(device_get_parent(dev)), dev, SYS_RES_MEMORY, rid, res )) != 0 ) device_printf( dev, "bus_release_resource() returned %d\n", ret ); return ENXIO; } /***********************/ /* eccmon_attach() */ /***********************/ static int eccmon_attach( const device_t const dev ) { device_printf( dev, "attach: started for %x:%x\n", pci_get_vendor( dev ) , pci_get_device( dev ) ); return ENXIO; } /***********************/ /* eccmon_detach() */ /***********************/ static int eccmon_detach( const device_t const dev ) { device_printf( dev, "detach: started for %x:%x\n", pci_get_vendor( dev ) , pci_get_device( dev ) ); return 0; } /*************************/ /* eccmon_identify() */ /*************************/ static void eccmon_identify( driver_t *driver, device_t p ) { device_printf( p, "identify: start: %x %x\n", pci_get_vendor( p ), pci_get_device( p ) ); device_printf( p, "identify on: %s %d\n", device_get_name( p ), device_get_unit(p) ); if( device_find_child( p, "eccmon", -1 ) == NULL && strcmp( device_get_name( p ), "hostb" ) == 0 && device_get_unit( p ) == 0 ) { device_t child = device_add_child( p, "eccmon", -1 ); device_printf( p, "identify added child: %p\n", child ); } } /***********************/ /* driver(9) stuff */ /***********************/ static device_method_t eccmon_methods[] = { DEVMETHOD( device_identify, eccmon_identify ), DEVMETHOD( device_probe, eccmon_probe ), DEVMETHOD( device_attach, eccmon_attach ), DEVMETHOD( device_detach, eccmon_detach ), { 0, 0 } }; static driver_t eccmon_driver = { "eccmon", eccmon_methods, sizeof( struct eccmon_softc ) }; static devclass_t eccmon_devclass; DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, NULL ); -------------------- eccmon.c end ------------------------------------- -------------------- Makefile start ------------------------------------- KMOD = eccmon SRCS = eccmon.c device_if.h bus_if.h pci_if.h NO_MAN = 1 CFLAGS+=-DDEVEL .include -------------------- Makefile end ------------------------------------- From lgusenet at be-well.ilk.org Fri Jul 24 15:11:40 2009 From: lgusenet at be-well.ilk.org (Lowell Gilbert) Date: Fri Jul 24 17:41:40 2009 Subject: SGID/SUID on scripts In-Reply-To: <200907240902.09609.j.mckeown@ru.ac.za> (Jonathan McKeown's message of "Fri\, 24 Jul 2009 09\:02\:09 +0200") References: <19939654343.20090722214221@mail.ru> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> <44my6v8d97.fsf@be-well.ilk.org> <200907240902.09609.j.mckeown@ru.ac.za> Message-ID: <44zlau6rpx.fsf@be-well.ilk.org> Jonathan McKeown writes: > On Thursday 23 July 2009 20:28:52 Lowell Gilbert wrote: >> That's clever, but how would it work in practice, while common shells >> and scripting languages may not implement their side of it? > > http://www.in-ulm.de/~mascheck/various/shebang/ claims that it's been > implemented, in exactly the way described, in Solaris, OpenBSD and NetBSD > (albeit as a kernel compile-time option in the latter two). (It's apparently > also in IRIX and UnixWare). > > Given OpenBSD's admirable paranoia about security (hey, I'm a sysadmin: I > never ask myself if I'm being paranoid, but if I'm being paranoid enough!) > I'd have thought they would have explored the implications fully. They don't enable it by default, and they don't seem to recommend it. > Certainly other stuff knows about it. As I said yesterday, Perl describes the > problem in its perlsec manpage/perldoc. The perl interpreter even has a > build-time option, SETUID_SCRIPTS_ARE_SECURE_NOW - and the correct setting is > supposedly detected as part of configure. The problem I'm wondering about is that it doesn't matter what knows about it as long as there's an interpreter that *doesn't*. Anything that opens a script parameter on its own (there are other vulnerable approaches, but one's enough) will be insecure. I may well be missing something, of course. > There may well be some problems to overcome, but this doesn't appear to be > unexplored territory. Not entirely, but there may well be a reason it's never been in common use. - Lowell From kostikbel at gmail.com Fri Jul 24 21:29:41 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 24 21:29:48 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724134953.GW68469@hoeg.nl> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> Message-ID: <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> On Fri, Jul 24, 2009 at 03:49:53PM +0200, Ed Schouten wrote: > * Jeremie Le Hen wrote: > > On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > > > * Jeremie Le Hen wrote: > > > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > > > Hi Ed, > > > > > > > > > > > > Sorry for the late reply. > > > > > > > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > > > We probably could. I think I discussed this with Robert Watson some time > > > > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > > > > prevent us from reaching this limitation later on. > > > > > > > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > > > I don't see where we can get randomness from it. > > > > > > > > > > The thing is called ELF auxillary information vector. It is used to > > > > > supply some useful information for interpreter from the kernel, > > > > > see include/machine/elf.h for AT_* entries. > > > > > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > > > generated at link time, that will be used to fill the canary at exec(2) > > > > time? > > > > > > Very short answer: yes! > > > > Ok thanks. But this would make stack protection useless for local > > attacks on suid binaries that are world-readable since the attacker > > could read the ELF aux vector and compute the canary. > > Wait wait wait. It seems you were only partially right (and Kostik > corrected you): > > We could add AT_RANDOM, but this value will be filled in by the kernel > when starting the process. This means the random value is not stored in > the binary. Below is the prototype that seems to work for me both with patched and old rtld on i386. Patch also contains bits for amd64 that I did not tested yet. All other arches are not buildable for now. Patch completely eliminates sysctl syscalls from the rtld and libc startup. Without the patch, a single run of /bin/ls did 6 sysctls, with the patch, no sysctls is queried at all. diff --git a/lib/libc/gen/__getosreldate.c b/lib/libc/gen/__getosreldate.c index 69aac07..6a4e5ea 100644 --- a/lib/libc/gen/__getosreldate.c +++ b/lib/libc/gen/__getosreldate.c @@ -29,6 +29,8 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include /* * This is private to libc. It is intended for wrapping syscall stubs in order @@ -49,7 +51,15 @@ __getosreldate(void) if (osreldate != 0) return (osreldate); - + + if (_rtld_aux_info != NULL) + error = _rtld_aux_info(AT_OSRELDATE, &osreldate, + sizeof(osreldate)); + else + error = ENOSYS; + if (error == 0 && osreldate != 0) + return (osreldate); + oid[0] = CTL_KERN; oid[1] = KERN_OSRELDATE; osrel = 0; diff --git a/lib/libc/gen/getpagesize.c b/lib/libc/gen/getpagesize.c index d796b9d..b8f0ec1 100644 --- a/lib/libc/gen/getpagesize.c +++ b/lib/libc/gen/getpagesize.c @@ -36,6 +36,8 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include #include /* @@ -52,13 +54,23 @@ getpagesize() int mib[2]; static int value; size_t size; + int error; + + if (value != 0) + return (value); + + if (_rtld_aux_info != NULL) + error = _rtld_aux_info(AT_PAGESZ, &value, sizeof(value)); + else + error = ENOSYS; + if (error == 0 && value != 0) + return (value); + + mib[0] = CTL_HW; + mib[1] = HW_PAGESIZE; + size = sizeof value; + if (sysctl(mib, 2, &value, &size, NULL, 0) == -1) + return (-1); - if (!value) { - mib[0] = CTL_HW; - mib[1] = HW_PAGESIZE; - size = sizeof value; - if (sysctl(mib, 2, &value, &size, NULL, 0) == -1) - return (-1); - } return (value); } diff --git a/lib/libc/stdlib/malloc.c b/lib/libc/stdlib/malloc.c index 270d641..e479abe 100644 --- a/lib/libc/stdlib/malloc.c +++ b/lib/libc/stdlib/malloc.c @@ -179,6 +179,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -4769,7 +4770,10 @@ malloc_init_hard(void) unsigned i; int linklen; char buf[PATH_MAX + 1]; + int mib[2]; + size_t len; const char *opts; + int error; malloc_mutex_lock(&init_lock); if (malloc_initialized) { @@ -4782,10 +4786,11 @@ malloc_init_hard(void) } /* Get number of CPUs. */ - { - int mib[2]; - size_t len; - + if (_rtld_aux_info != NULL) + error = _rtld_aux_info(AT_NCPUS, &ncpus, sizeof(ncpus)); + else + error = ENOSYS; + if (error != 0 || ncpus == 0) { mib[0] = CTL_HW; mib[1] = HW_NCPU; len = sizeof(ncpus); diff --git a/lib/libc/sys/stack_protector.c b/lib/libc/sys/stack_protector.c index 63beebc..571f63c 100644 --- a/lib/libc/sys/stack_protector.c +++ b/lib/libc/sys/stack_protector.c @@ -34,6 +34,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include @@ -54,9 +56,17 @@ __guard_setup(void) { int mib[2]; size_t len; + int error; if (__stack_chk_guard[0] != 0) return; + if (_rtld_aux_info != NULL) + error = _rtld_aux_info(AT_CANARY, __stack_chk_guard, + sizeof(__stack_chk_guard)); + else + error = ENOSYS; + if (error == 0 && __stack_chk_guard[0] != 0) + return; mib[0] = CTL_KERN; mib[1] = KERN_ARND; diff --git a/libexec/rtld-elf/Symbol.map b/libexec/rtld-elf/Symbol.map index ce1e3e5..f45f955 100644 --- a/libexec/rtld-elf/Symbol.map +++ b/libexec/rtld-elf/Symbol.map @@ -24,4 +24,5 @@ FBSDprivate_1.0 { _rtld_free_tls; _rtld_atfork_pre; _rtld_atfork_post; + _rtld_aux_info; }; diff --git a/libexec/rtld-elf/amd64/reloc.c b/libexec/rtld-elf/amd64/reloc.c index 8a32adf..a510884 100644 --- a/libexec/rtld-elf/amd64/reloc.c +++ b/libexec/rtld-elf/amd64/reloc.c @@ -113,7 +113,7 @@ init_pltgot(Obj_Entry *obj) /* Process the non-PLT relocations. */ int -reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) +reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, bool early) { const Elf_Rela *relalim; const Elf_Rela *rela; @@ -125,9 +125,13 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) * The dynamic loader may be called from a thread, we have * limited amounts of stack available so we cannot use alloca(). */ - cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); - if (cache == MAP_FAILED) + if (early) cache = NULL; + else { + cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); + if (cache == MAP_FAILED) + cache = NULL; + } relalim = (const Elf_Rela *) ((caddr_t) obj->rela + obj->relasize); for (rela = obj->rela; rela < relalim; rela++) { diff --git a/libexec/rtld-elf/i386/reloc.c b/libexec/rtld-elf/i386/reloc.c index ec83bff..2913d78 100644 --- a/libexec/rtld-elf/i386/reloc.c +++ b/libexec/rtld-elf/i386/reloc.c @@ -114,7 +114,7 @@ init_pltgot(Obj_Entry *obj) /* Process the non-PLT relocations. */ int -reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) +reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, bool early) { const Elf_Rel *rellim; const Elf_Rel *rel; @@ -126,9 +126,13 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) * The dynamic loader may be called from a thread, we have * limited amounts of stack available so we cannot use alloca(). */ - cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); - if (cache == MAP_FAILED) + if (early) cache = NULL; + else { + cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); + if (cache == MAP_FAILED) + cache = NULL; + } rellim = (const Elf_Rel *) ((caddr_t) obj->rel + obj->relsize); for (rel = obj->rel; rel < rellim; rel++) { diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 721fe89..75a1c69 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -84,6 +85,9 @@ typedef struct Struct_DoneList { */ static const char *basename(const char *); static void die(void) __dead2; +static void digest_dynamic1(Obj_Entry *, int, const Elf_Dyn **, + const Elf_Dyn **); +static void digest_dynamic2(Obj_Entry *, const Elf_Dyn *, const Elf_Dyn *); static void digest_dynamic(Obj_Entry *, int); static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char *); static Obj_Entry *dlcheck(void *); @@ -97,7 +101,7 @@ static char *find_library(const char *, const Obj_Entry *); static const char *gethints(void); static void init_dag(Obj_Entry *); static void init_dag1(Obj_Entry *, Obj_Entry *, DoneList *); -static void init_rtld(caddr_t); +static void init_rtld(caddr_t, Elf_Auxinfo **); static void initlist_add_neededs(Needed_Entry *, Objlist *); static void initlist_add_objects(Obj_Entry *, Obj_Entry **, Objlist *); static bool is_exported(const Elf_Sym *); @@ -116,7 +120,7 @@ static void objlist_push_head(Objlist *, Obj_Entry *); static void objlist_push_tail(Objlist *, Obj_Entry *); static void objlist_remove(Objlist *, Obj_Entry *); static void *path_enumerate(const char *, path_enum_proc, void *); -static int relocate_objects(Obj_Entry *, bool, Obj_Entry *); +static int relocate_objects(Obj_Entry *, bool, Obj_Entry *, bool early); static int rtld_dirname(const char *, char *); static int rtld_dirname_abs(const char *, char *); static void rtld_exit(void); @@ -188,6 +192,9 @@ extern Elf_Dyn _DYNAMIC; #define RTLD_IS_DYNAMIC() (&_DYNAMIC != NULL) #endif +static int pagesize, osreldate, canary_len, ncpus; +static char *canary; + /* * These are the functions the dynamic linker exports to application * programs. They are the only symbols the dynamic linker is willing @@ -214,6 +221,7 @@ static func_ptr_type exports[] = { (func_ptr_type) &dl_iterate_phdr, (func_ptr_type) &_rtld_atfork_pre, (func_ptr_type) &_rtld_atfork_post, + (func_ptr_type) &_rtld_aux_info, NULL }; @@ -350,7 +358,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry **objp) /* Initialize and relocate ourselves. */ assert(aux_info[AT_BASE] != NULL); - init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr); + init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr, aux_info); __progname = obj_rtld.path; argv0 = argv[0] != NULL ? argv[0] : "(null)"; @@ -519,7 +527,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry **objp) allocate_initial_tls(obj_list); if (relocate_objects(obj_main, - ld_bind_now != NULL && *ld_bind_now != '\0', &obj_rtld) == -1) + ld_bind_now != NULL && *ld_bind_now != '\0', &obj_rtld, false) == -1) die(); dbg("doing copy relocations"); @@ -736,14 +744,16 @@ die(void) * information in its Obj_Entry structure. */ static void -digest_dynamic(Obj_Entry *obj, int early) +digest_dynamic1(Obj_Entry *obj, int early, const Elf_Dyn **dyn_rpath, + const Elf_Dyn **dyn_soname) { const Elf_Dyn *dynp; Needed_Entry **needed_tail = &obj->needed; - const Elf_Dyn *dyn_rpath = NULL; - const Elf_Dyn *dyn_soname = NULL; int plttype = DT_REL; + *dyn_rpath = NULL; + *dyn_soname = NULL; + obj->bind_now = false; for (dynp = obj->dynamic; dynp->d_tag != DT_NULL; dynp++) { switch (dynp->d_tag) { @@ -867,11 +877,11 @@ digest_dynamic(Obj_Entry *obj, int early) * We have to wait until later to process this, because we * might not have gotten the address of the string table yet. */ - dyn_rpath = dynp; + *dyn_rpath = dynp; break; case DT_SONAME: - dyn_soname = dynp; + *dyn_soname = dynp; break; case DT_INIT: @@ -958,6 +968,12 @@ digest_dynamic(Obj_Entry *obj, int early) obj->pltrelasize = obj->pltrelsize; obj->pltrelsize = 0; } +} + +static void +digest_dynamic2(Obj_Entry *obj, const Elf_Dyn *dyn_rpath, + const Elf_Dyn *dyn_soname) +{ if (obj->z_origin && obj->origin_path == NULL) { obj->origin_path = xmalloc(PATH_MAX); @@ -975,6 +991,16 @@ digest_dynamic(Obj_Entry *obj, int early) object_add_name(obj, obj->strtab + dyn_soname->d_un.d_val); } +static void +digest_dynamic(Obj_Entry *obj, int early) +{ + const Elf_Dyn *dyn_rpath; + const Elf_Dyn *dyn_soname; + + digest_dynamic1(obj, early, &dyn_rpath, &dyn_soname); + digest_dynamic2(obj, dyn_rpath, dyn_soname); +} + /* * Process a shared object's program header. This is used only for the * main program, when the kernel has already loaded the main program @@ -1301,9 +1327,11 @@ init_dag1(Obj_Entry *root, Obj_Entry *obj, DoneList *dlp) * this function is to relocate the dynamic linker. */ static void -init_rtld(caddr_t mapbase) +init_rtld(caddr_t mapbase, Elf_Auxinfo **aux_info) { Obj_Entry objtmp; /* Temporary rtld object */ + const Elf_Dyn *dyn_rpath; + const Elf_Dyn *dyn_soname; /* * Conjure up an Obj_Entry structure for the dynamic linker. @@ -1320,27 +1348,38 @@ init_rtld(caddr_t mapbase) #endif if (RTLD_IS_DYNAMIC()) { objtmp.dynamic = rtld_dynamic(&objtmp); - digest_dynamic(&objtmp, 1); + digest_dynamic1(&objtmp, 1, &dyn_rpath, &dyn_soname); assert(objtmp.needed == NULL); #if !defined(__mips__) /* MIPS and SH{3,5} have a bogus DT_TEXTREL. */ assert(!objtmp.textrel); #endif - /* * Temporarily put the dynamic linker entry into the object list, so * that symbols can be found. */ - relocate_objects(&objtmp, true, &objtmp); + relocate_objects(&objtmp, true, &objtmp, true); } - /* Initialize the object list. */ obj_tail = &obj_list; /* Now that non-local variables can be accesses, copy out obj_rtld. */ memcpy(&obj_rtld, &objtmp, sizeof(obj_rtld)); + if (aux_info[AT_PAGESZ] != NULL) + pagesize = aux_info[AT_PAGESZ]->a_un.a_val; + if (aux_info[AT_OSRELDATE] != NULL) + osreldate = aux_info[AT_OSRELDATE]->a_un.a_val; + if (aux_info[AT_CANARY] != NULL && aux_info[AT_CANARYLEN] != NULL) { + canary = aux_info[AT_CANARY]->a_un.a_ptr; + canary_len = aux_info[AT_CANARYLEN]->a_un.a_val; + } + if (aux_info[AT_NCPUS] != NULL) + ncpus = aux_info[AT_NCPUS]->a_un.a_val; + + digest_dynamic2(&obj_rtld, dyn_rpath, dyn_soname); + /* Replace the path with a dynamically allocated copy. */ obj_rtld.path = xstrdup(PATH_RTLD); @@ -1745,7 +1784,8 @@ objlist_remove(Objlist *list, Obj_Entry *obj) * or -1 on failure. */ static int -relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj) +relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj, + bool early) { Obj_Entry *obj; @@ -1770,7 +1810,7 @@ relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj) } /* Process the non-PLT relocations. */ - if (reloc_non_plt(obj, rtldobj)) + if (reloc_non_plt(obj, rtldobj, early)) return -1; if (obj->textrel) { /* Re-protected the text segment. */ @@ -2022,7 +2062,8 @@ dlopen(const char *name, int mode) if (result != -1 && ld_tracing) goto trace; if (result == -1 || - (relocate_objects(obj, mode == RTLD_NOW, &obj_rtld)) == -1) { + (relocate_objects(obj, mode == RTLD_NOW, &obj_rtld, false)) + == -1) { obj->dl_refcount--; unref_dag(obj); if (obj->refcount == 0) @@ -3611,3 +3652,110 @@ fetch_ventry(const Obj_Entry *obj, unsigned long symnum) } return NULL; } + +static int +__getosreldate(void) +{ + static int osreldate; + size_t len; + int oid[2]; + int error, osrel; + + oid[0] = CTL_KERN; + oid[1] = KERN_OSRELDATE; + osrel = 0; + len = sizeof(osrel); + error = sysctl(oid, 2, &osrel, &len, NULL, 0); + if (error == 0 && osrel > 0 && len == sizeof(osrel)) + osreldate = osrel; + return (osreldate); +} + +static int +__getpagesize(void) +{ + int mib[2]; + static int value; + size_t size; + + mib[0] = CTL_HW; + mib[1] = HW_PAGESIZE; + size = sizeof value; + if (sysctl(mib, 2, &value, &size, NULL, 0) == -1) + return (-1); + + return (value); +} + +static int +__getncpus(void) +{ + int mib[2]; + size_t len; + int n; + + mib[0] = CTL_HW; + mib[1] = HW_NCPU; + len = sizeof(ncpus); + if (sysctl(mib, 2, &n, &len, (void *) 0, 0) == -1) + n = 1; + return (n); +} + +int +_rtld_aux_info(int aux, void *buf, int buflen) +{ + int res; + + switch (aux) { + case AT_CANARY: + if (canary != NULL && canary_len >= buflen) { + memcpy(buf, canary, buflen); + memset(canary, 0, canary_len); + canary = NULL; + res = 0; + } else + res = ENOENT; + break; + case AT_PAGESZ: + if (buflen == sizeof(int)) { + if (pagesize == 0) + pagesize = __getpagesize(); + if (pagesize != 0) { + *(int *)buf = pagesize; + res = 0; + } else + res = ENOENT; + } else + res = EINVAL; + break; + case AT_OSRELDATE: + if (buflen == sizeof(int)) { + if (osreldate == 0) + osreldate = __getosreldate(); + if (osreldate != 0) { + *(int *)buf = osreldate; + res = 0; + } else + res = ENOENT; + } else + res = EINVAL; + break; + case AT_NCPUS: + if (buflen == sizeof(int)) { + if (ncpus == 0) + ncpus = __getncpus(); + if (ncpus != 0) { + *(int *)buf = ncpus; + res = 0; + } else + res = ENOENT; + } else + res = EINVAL; + break; + default: + res = ENOENT; + break; + } + return (res); +} diff --git a/libexec/rtld-elf/rtld.h b/libexec/rtld-elf/rtld.h index 06086b4..928e3ed 100644 --- a/libexec/rtld-elf/rtld.h +++ b/libexec/rtld-elf/rtld.h @@ -286,7 +286,7 @@ const Ver_Entry *fetch_ventry(const Obj_Entry *obj, unsigned long); * MD function declarations. */ int do_copy_relocations(Obj_Entry *); -int reloc_non_plt(Obj_Entry *, Obj_Entry *); +int reloc_non_plt(Obj_Entry *, Obj_Entry *, bool); int reloc_plt(Obj_Entry *); int reloc_jmpslots(Obj_Entry *); void allocate_initial_tls(Obj_Entry *); diff --git a/sys/amd64/include/elf.h b/sys/amd64/include/elf.h index e5c95f7..d541b9e 100644 --- a/sys/amd64/include/elf.h +++ b/sys/amd64/include/elf.h @@ -87,8 +87,12 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_COUNT 20 /* Count of defined aux entry types. */ /* * Relocation types. diff --git a/sys/compat/ia32/ia32_sysvec.c b/sys/compat/ia32/ia32_sysvec.c index af8168e..acf2c34 100644 --- a/sys/compat/ia32/ia32_sysvec.c +++ b/sys/compat/ia32/ia32_sysvec.c @@ -191,6 +191,7 @@ ia32_copyout_strings(struct image_params *imgp) struct freebsd32_ps_strings *arginfo; size_t execpath_len; int szsigcode; + char canary[sizeof(long) * 8]; /* * Calculate string base and vector table pointers. @@ -203,8 +204,9 @@ ia32_copyout_strings(struct image_params *imgp) arginfo = (struct freebsd32_ps_strings *)FREEBSD32_PS_STRINGS; szsigcode = *(imgp->proc->p_sysent->sv_szsigcode); destp = (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - - roundup(execpath_len, sizeof(char *)) - - roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); + roundup(execpath_len, sizeof(char *)) - + roundup(sizeof(canary), sizeof(char *)) - + roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); /* * install sigcode @@ -223,6 +225,14 @@ ia32_copyout_strings(struct image_params *imgp) } /* + * Prepare the canary for SSP. + */ + arc4rand(canary, sizeof(canary), 0); + imgp->canary = (uintptr_t)arginfo - szsigcode - execpath_len - + sizeof(canary); + copyout(canary, (void *)imgp->canary, sizeof(canary)); + + /* * If we have a valid auxargs ptr, prepare some room * on the stack. */ @@ -239,8 +249,8 @@ ia32_copyout_strings(struct image_params *imgp) * for argument of Runtime loader. */ vectp = (u_int32_t *) (destp - (imgp->args->argc + - imgp->args->envc + 2 + imgp->auxarg_size + execpath_len) * - sizeof(u_int32_t)); + imgp->args->envc + 2 + imgp->auxarg_size) + * sizeof(u_int32_t)); } else /* * The '+ 2' is for the null pointers at the end of each of diff --git a/sys/i386/include/elf.h b/sys/i386/include/elf.h index af71ab8..a959e68 100644 --- a/sys/i386/include/elf.h +++ b/sys/i386/include/elf.h @@ -90,8 +90,12 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ +#define AT_CANARY 16 /* Canary for SSP. */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_COUNT 20 /* Count of defined aux entry types. */ /* * Relocation types. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index e2c0a12..b2c1d45 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -50,6 +50,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -887,6 +888,12 @@ __elfN(freebsd_fixup)(register_t **stack_base, struct image_params *imgp) AUXARGS_ENTRY(pos, AT_BASE, args->base); if (imgp->execpathp != 0) AUXARGS_ENTRY(pos, AT_EXECPATH, imgp->execpathp); + AUXARGS_ENTRY(pos, AT_OSRELDATE, imgp->proc->p_osrel); + if (imgp->canary != 0) { + AUXARGS_ENTRY(pos, AT_CANARY, imgp->canary); + AUXARGS_ENTRY(pos, AT_CANARYLEN, imgp->canarylen); + } + AUXARGS_ENTRY(pos, AT_NCPUS, mp_ncpus); AUXARGS_ENTRY(pos, AT_NULL, 0); free(imgp->auxargs, M_TEMP); diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 3f36658..6bed93f 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -380,6 +380,8 @@ do_execve(td, args, mac_p) imgp->args = args; imgp->execpath = imgp->freepath = NULL; imgp->execpathp = 0; + imgp->canary = 0; + imgp->canarylen = 0; #ifdef MAC error = mac_execve_enter(imgp, mac_p); @@ -1175,6 +1177,7 @@ exec_copyout_strings(imgp) struct proc *p; size_t execpath_len; int szsigcode; + char canary[sizeof(long) * 8]; /* * Calculate string base and vector table pointers. @@ -1191,6 +1194,7 @@ exec_copyout_strings(imgp) szsigcode = *(p->p_sysent->sv_szsigcode); destp = (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - roundup(execpath_len, sizeof(char *)) - + roundup(sizeof(canary), sizeof(char *)) - roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); /* @@ -1210,6 +1214,15 @@ exec_copyout_strings(imgp) } /* + * Prepare the canary for SSP. + */ + arc4rand(canary, sizeof(canary), 0); + imgp->canary = (uintptr_t)arginfo - szsigcode - execpath_len - + sizeof(canary); + copyout(canary, (void *)imgp->canary, sizeof(canary)); + imgp->canarylen = sizeof(canary); + + /* * If we have a valid auxargs ptr, prepare some room * on the stack. */ @@ -1226,8 +1239,8 @@ exec_copyout_strings(imgp) * for argument of Runtime loader. */ vectp = (char **)(destp - (imgp->args->argc + - imgp->args->envc + 2 + imgp->auxarg_size + execpath_len) * - sizeof(char *)); + imgp->args->envc + 2 + imgp->auxarg_size) + * sizeof(char *)); } else { /* * The '+ 2' is for the null pointers at the end of each of diff --git a/sys/sys/imgact.h b/sys/sys/imgact.h index e6acc00..8acd184 100644 --- a/sys/sys/imgact.h +++ b/sys/sys/imgact.h @@ -69,6 +69,8 @@ struct image_params { char *execpath; unsigned long execpathp; char *freepath; + unsigned long canary; + int canarylen; }; #ifdef _KERNEL diff --git a/sys/sys/link_elf.h b/sys/sys/link_elf.h index 98840a5..30f3d75 100644 --- a/sys/sys/link_elf.h +++ b/sys/sys/link_elf.h @@ -92,6 +92,10 @@ __BEGIN_DECLS typedef int (*__dl_iterate_hdr_callback)(struct dl_phdr_info *, size_t, void *); extern int dl_iterate_phdr(__dl_iterate_hdr_callback, void *); +extern int _rtld_aux_info(int, void *, int); +#ifndef IN_RTLD +#pragma weak _rtld_aux_info +#endif __END_DECLS -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090724/6a39604e/attachment.pgp From unixmania at gmail.com Sat Jul 25 01:47:45 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sat Jul 25 01:47:51 2009 Subject: SGID/SUID on scripts In-Reply-To: <19939654343.20090722214221@mail.ru> References: <19939654343.20090722214221@mail.ru> Message-ID: On Wed, Jul 22, 2009 at 2:42 PM, Anthony Pankov wrote: > > SGID/SUID bits don't work with shell scripts, do they? No. A possible workaround is have a SUID/SGID version of you interpreter and use it. Something like # pw groupadd -n sush -g 401 # cp /bin/sh /bin/sush # chown root:sush /bin/sush # chmod 4750 /bin/sush # pw usermod johndoe -G sush Then start your script with "#!/bin/sush" and user johndoe,as well as any member of the "sush" group will be able to it run as root. I think I don't need to warn you that they will be able to run *any* command as root, in fact. For a better approach, consider using sudo, instead (/usr/ports/security/sudo). -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From gary.jennejohn at freenet.de Sat Jul 25 13:01:57 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Jul 25 13:02:04 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> Message-ID: <20090725150154.4f36e0ce@ernst.jennejohn.org> On Sat, 25 Jul 2009 00:29:16 +0300 Kostik Belousov wrote: > Below is the prototype that seems to work for me both with patched and > old rtld on i386. Patch also contains bits for amd64 that I did not > tested yet. All other arches are not buildable for now. > [patch deleted] I'm currently running the patch under AMD64 and haven't noticed any regressiosn yet. --- Gary Jennejohn From kostikbel at gmail.com Sat Jul 25 13:32:03 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Jul 25 13:32:10 2009 Subject: concurrent sysctl implementation In-Reply-To: <20090725150154.4f36e0ce@ernst.jennejohn.org> References: <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> <20090725150154.4f36e0ce@ernst.jennejohn.org> Message-ID: <20090725133157.GT55190@deviant.kiev.zoral.com.ua> On Sat, Jul 25, 2009 at 03:01:54PM +0200, Gary Jennejohn wrote: > On Sat, 25 Jul 2009 00:29:16 +0300 > Kostik Belousov wrote: > > > Below is the prototype that seems to work for me both with patched and > > old rtld on i386. Patch also contains bits for amd64 that I did not > > tested yet. All other arches are not buildable for now. > > > [patch deleted] > > I'm currently running the patch under AMD64 and haven't noticed any > regressiosn yet. Thank you. It is interesting how much sysctls are issued for startup. Easier way to see that is to ktrace /bin/ls and then do kdump | grep SCTL. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090725/c38b7afe/attachment.pgp From Andre.Albsmeier at siemens.com Sat Jul 25 13:56:37 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Sat Jul 25 13:56:44 2009 Subject: SOLVED: Reading acpi memory from a driver attached to hostb In-Reply-To: <200907231606.11904.jhb@freebsd.org> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> <20090723175351.GA70584@curry.mchp.siemens.de> <200907231606.11904.jhb@freebsd.org> Message-ID: <20090725135632.GA77656@curry.mchp.siemens.de> On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote: > On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote: > > John, apparently you sent me an email (thanks a lot) which I never > > received (we have to blame our company's spam filters which I do > > not control). I'll comment on it here in my reply to Doug... > > Yes, I saw the bounces. Hopefully you see the list version of this. > > > > | Did you try > > > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in > your > > > | driver that is a child of hostb0? > > > > I tried this, well, something similar: I had to do 4 times > > device_get_parent() to end up at acpi0: > > > > mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 > > You don't actually need to do that. pci0 will pass the request up to acpi0 > eventually. You just need to ask pci0 to allocate it for you and it will see > you are not a direct child and take the 'passthrough' case here: > > struct resource * > pci_alloc_resource(device_t dev, device_t child, int type, int *rid, > u_long start, u_long end, u_long count, u_int flags) > { > ... > > if (device_get_parent(child) != dev) > return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, > type, rid, start, end, count, flags)); > ... > } > > Rather than trying to allocate the whole chunk of the ACPI resource, I would > just do a specific allocation like so: > > rid = 0; > res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), > dev, SYS_RES_MEMORY, &rid, , end address>, , RF_ACTIVE); I finally got it working. Many thanks to all, especially to Doug and John. It should have worked all the time with John's code above but due to a stupidity on my part (I specified "end" as "start + count" and not as "start + count - 1") the allocation failed. It was Doug's suggestion to disable resource allocation in acpi.c -- so the memory area was unused and I could allocate it. After entering some debugging code into acpi_resource.c and acpi.c, which do not forgive errors like the above, I found my bug ;-) No I learned a bit about acpi and found curious things like this: When using BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)), ... it is pci0 appearing in acpi_alloc_resource() to allocate the resource with the parameters I specify (count == 0x4000). When using only BUS_ALLOC_RESOURCE( device_get_parent(dev), ... it is hostb0 appearing in acpi_alloc_resource() but count got changed to 0x80. However start and end remain unchanged and do not match end = start + count - 1 anymore. Thanks again, -Andre From gabor at kovesdan.org Sun Jul 26 08:48:57 2009 From: gabor at kovesdan.org (=?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?=) Date: Sun Jul 26 14:49:52 2009 Subject: bsd.lib.mk question Message-ID: <4A6C1508.7020309@kovesdan.org> Hi, I wonder if there's a conventional way of building _only_ shared libraries using bsd.lib.mk. At default, it builds static, shared and profiled libraries, which is a waste of time because I only need shared libraries, which I use as on-demand loadable modules. Adjusting _LIBS after the inclusion of bsd.lib.mk doesn't help and there are no knobs to control the behaviour. What should I do? Thanks, G?bor From ed at 80386.nl Sun Jul 26 17:01:09 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Jul 26 17:01:15 2009 Subject: bsd.lib.mk question In-Reply-To: <4A6C1508.7020309@kovesdan.org> References: <4A6C1508.7020309@kovesdan.org> Message-ID: <20090726170107.GE83812@hoeg.nl> Hi Gabor, * G?bor K?vesd?n wrote: > I wonder if there's a conventional way of building _only_ shared > libraries using bsd.lib.mk. At default, it builds static, shared and > profiled libraries, which is a waste of time because I only need > shared libraries, which I use as on-demand loadable modules. > Adjusting _LIBS after the inclusion of bsd.lib.mk doesn't help and > there are no knobs to control the behaviour. What should I do? Be sure to look at the Makefiles used by the PAM modules (lib/libpam/modules). I guess NO_PROFILE and NO_INSTALLLIB should be sufficient. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090726/98f23ab6/attachment.pgp From gal.diskin at intel.com Sun Jul 26 15:39:54 2009 From: gal.diskin at intel.com (Diskin, Gal) Date: Sun Jul 26 17:33:56 2009 Subject: ptrace question Message-ID: Hi, I'm using ptrace to execute one application under the control of another (surprisingly :P). I'm trying to find the number of the last system call executed in the traced process from the tracing process. In Linux this is done using "orig_eax" (or "orig_rax") but as far as I can tell it does not have a counterpart in FreeBSD (correct me if I'm wrong). I've looked at the kernel sources in hope of finding out how the conversion was done in the Linux emulation layer. The file linux_ptrace.c (http://fxr.watson.org/fxr/source/i386/linux/linux_ptrace.c?v=FREEBSD72#L118) seems to be the place the conversion is taking place. However, in spite the comment at the top of the conversion function mentioning that the translation is not straightforward, the translation done is simply copying eax to orig_eax. My question is: Is there a way to find the number of the last system call executed in the traced application from the tracing application (using ptrace)? Thanks, Gal Diskin --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From kostikbel at gmail.com Sun Jul 26 17:49:53 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Jul 26 17:50:00 2009 Subject: ptrace question In-Reply-To: References: Message-ID: <20090726174946.GR55190@deviant.kiev.zoral.com.ua> On Sun, Jul 26, 2009 at 06:11:25PM +0300, Diskin, Gal wrote: > Hi, > I'm using ptrace to execute one application under the control > of another (surprisingly :P). I'm trying to find the number > of the last system call executed in the traced process from > the tracing process. In Linux this is done using "orig_eax" > (or "orig_rax") but as far as I can tell it does not have a > counterpart in FreeBSD (correct me if I'm wrong). I've looked > at the kernel sources in hope of finding out how the conversion > was done in the Linux emulation layer. The file linux_ptrace.c > (http://fxr.watson.org/fxr/source/i386/linux/linux_ptrace.c?v=FREEBSD7 > 2#L118) seems to be the place the conversion is taking place. However, > in spite the comment at the top of the conversion function mentioning > that the translation is not straightforward, the translation done is > simply copying eax to orig_eax. > > My question is: Is there a way to find the number of the last system > call executed in the traced application from the tracing application > (using ptrace)? Are you trying to trace linux process, or native freebsd ? And, is the tracer linux process, or freebsd one ? It seems that you are talking about linux process, note that linux PTRACE_SYSCALL is not implemented in linuxolator. For native FreeBSD tracers, you can use PT_TO_SCE, that stops the process at the syscall entry, PT_TO_SCX, that stops at the syscall exit. Most likely, truss source code is most illustrative in the usage. The flags allow to trace both freebsd and linux processes. After the process is stopped, you should get registers of the traced process. Upon syscall entry, %eax contains syscall number. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090726/f6742e24/attachment.pgp From alfred at freebsd.org Sun Jul 26 23:34:43 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Sun Jul 26 23:34:49 2009 Subject: distributed scm+freebsd svn? Message-ID: <20090726231534.GI21885@elvis.mu.org> Hello hackers, Does anyone here use one of the distributed SCMs to manage contributions to FreeBSD in an easy manner? Any pointers to a setup you have? I thought "git" was supposed to make this easy, but going over the docs leaves me with a lot of questions. I'm hoping to be able to basically: sync into my "distributed repo". allow a third party access to it. easily commit upstream back into svn from a branch in my distributed scm. -- - Alfred Perlstein VMOA #5191, 03 vmax, 92 gs500, ch250 - FreeBSD From gal.diskin at intel.com Mon Jul 27 09:45:49 2009 From: gal.diskin at intel.com (Diskin, Gal) Date: Mon Jul 27 09:45:55 2009 Subject: ptrace question In-Reply-To: <20090726174946.GR55190@deviant.kiev.zoral.com.ua> References: <20090726174946.GR55190@deviant.kiev.zoral.com.ua> Message-ID: Hi Kostik, I'm tracing a native FreeBSD process. I tried looking at the Linux code to find a hint how to port my existing Linux code to FreeBSD. This is exactly what I was looking for - Thank you! Thanks, Gal -----Original Message----- From: Kostik Belousov [mailto:kostikbel@gmail.com] Sent: Sunday, July 26, 2009 8:50 PM To: Diskin, Gal Cc: freebsd-hackers@freebsd.org Subject: Re: ptrace question On Sun, Jul 26, 2009 at 06:11:25PM +0300, Diskin, Gal wrote: > Hi, > I'm using ptrace to execute one application under the control > of another (surprisingly :P). I'm trying to find the number > of the last system call executed in the traced process from > the tracing process. In Linux this is done using "orig_eax" > (or "orig_rax") but as far as I can tell it does not have a > counterpart in FreeBSD (correct me if I'm wrong). I've looked > at the kernel sources in hope of finding out how the conversion > was done in the Linux emulation layer. The file linux_ptrace.c > (http://fxr.watson.org/fxr/source/i386/linux/linux_ptrace.c?v=FREEBSD7 > 2#L118) seems to be the place the conversion is taking place. However, > in spite the comment at the top of the conversion function mentioning > that the translation is not straightforward, the translation done is > simply copying eax to orig_eax. > > My question is: Is there a way to find the number of the last system > call executed in the traced application from the tracing application > (using ptrace)? Are you trying to trace linux process, or native freebsd ? And, is the tracer linux process, or freebsd one ? It seems that you are talking about linux process, note that linux PTRACE_SYSCALL is not implemented in linuxolator. For native FreeBSD tracers, you can use PT_TO_SCE, that stops the process at the syscall entry, PT_TO_SCX, that stops at the syscall exit. Most likely, truss source code is most illustrative in the usage. The flags allow to trace both freebsd and linux processes. After the process is stopped, you should get registers of the traced process. Upon syscall entry, %eax contains syscall number. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From stas at FreeBSD.org Mon Jul 27 10:05:58 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Mon Jul 27 10:06:05 2009 Subject: distributed scm+freebsd svn? In-Reply-To: <20090726231534.GI21885@elvis.mu.org> References: <20090726231534.GI21885@elvis.mu.org> Message-ID: <20090727140550.585aa384.stas@FreeBSD.org> On Sun, 26 Jul 2009 16:15:34 -0700 Alfred Perlstein mentioned: > Hello hackers, > > Does anyone here use one of the distributed SCMs > to manage contributions to FreeBSD in an easy > manner? > > Any pointers to a setup you have? > > I thought "git" was supposed to make this easy, but > going over the docs leaves me with a lot of questions. > > I'm hoping to be able to basically: > sync into my "distributed repo". > allow a third party access to it. > easily commit upstream back into svn from a branch > in my distributed scm. > Hi, Alfred! As far as I know there's a lot of people in the communtity use distributed SCMs to work with FreeBSD repo: both git and mercurial are popular. I only used mercurial so I can share my experience only on this SCM. Since I started using it (about 2 years ago) I explored a number of possible ways to keep my repo in sync with FreeBSD one to make merges easier starting from hourly syncs by simple "cvsup + hg commit" (outlined at wiki) and ending by full repository conversions. Luckily enough after switch to subversion it is now possibleto convert the full repo with all history both to git and hg without much problem. Currently I'm using the Hg convert extentsion bundled into the default mercurial install. I made the result of conversion available here: http://repoman.deglitch.com/bsdhg/FreeBSD/base/ It is updated regularly (every 15 minutes) from the local svn mirror. The size of converted repo is about 885 MiB (with all known branches and tags and entire history). Some points to note if you will try do the initial conversion yourself: 1) Use memory disk for repository storage. That will spedup things a lot (an order of magnitude). 2) Hg convert extension expect the default svn layout (i.e. trunk/ for head, tags/ for tags and branches/ for branches). FreeBSD doesn't follow this layout so I had to tweak the application by hand to allow it to found our branches. It is possible to use command line switches to point it to your trunk, tags and branches location, but as we effectively have two root-level folders for branches (stable/ and releng/) it doesn't work well, so I had to add yet one switch to point to another branches folder. 3) Using local svn mirror is usually preferrable for performance matters. For development I usually do a branch clone (either from "head" branch, or some "stable" branch depending what I'm going to work on) by "hg clone" command and then do my work in that branch (ordiary commit/pull/push workflow, nothing specific). Whenever I need to sync with head I do a pull from the parent branch (e.g. hg pull -r head ssh://stas@repoman.deglitch.com/bsdhg/FreeBSD/base/) and then hg merge -r head. This works like a charm for any kind of work I do. When there's a need to get a diff between the stock FreeBSD tree and you tree you can achieve this by using hg diff -r "youbranch" -r "head". I do not perform commits directly from mercurial, but there're extensions to do this, afaik. This just doesn't sound useful much for me. Access to 3rd party users can be granted the same way it is done in other source control systems. I prefer the plain ssh access for this task by configuring a jail with repository access and creating users accounts with limited access and the special wrapper instead of login shell which allows execution of the limited set of commands. Today such kind of shell is already included into the distribution so there's no need to hack up your own version. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090727/a286f8af/attachment.pgp From avg at freebsd.org Mon Jul 27 10:33:00 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Jul 27 10:33:12 2009 Subject: distributed scm+freebsd svn? In-Reply-To: <20090726231534.GI21885@elvis.mu.org> References: <20090726231534.GI21885@elvis.mu.org> Message-ID: <4A6D7EBE.7080304@freebsd.org> on 27/07/2009 02:15 Alfred Perlstein said the following: > Hello hackers, > > Does anyone here use one of the distributed SCMs > to manage contributions to FreeBSD in an easy > manner? > > Any pointers to a setup you have? > > I thought "git" was supposed to make this easy, but > going over the docs leaves me with a lot of questions. > > I'm hoping to be able to basically: > sync into my "distributed repo". > allow a third party access to it. > easily commit upstream back into svn from a branch > in my distributed scm. I am using git for all of the above. It works quite satisfactory, but there is one major annoyance - git-svn doesn't understand svn mergeinfo. As such merges done in svn are not recorded in git. And MFC done in git (e.g. via cherry-pick) won't get propagated as svn merge on dcommit. Some info on my setup. I have 3 git repositories: - main one ("svn"), it is used for git-svn syncing and it tracks head, stable/7 and stable/6 svn branches; - "stable7", used for stable/7 development; - "head", used for head/current development; I think of "stable7" and "head" repositories as heavy-wait branches. In these repositories I have a master branch where I track svn through "svn" repository and I also have "light-weight" git branches for topic development. Typical work-cycle (e.g. for head): 1. develop in a topic branch of "head" repository 2. once development goal is achieved merge changes to master branch 3. rebase changes so that all commits are on top of all svn commits (and not interlaced with them) 4. further improve local commits, e.g. split, merge, change commit messages, etc 5. test and review 6. push changes to the corresponding branch of "svn" repository 7. dcommit in "svn" repository, changes go to svn This works quite well for head development and also for local changes that are not meant to go to svn. Unfortunately, as I said in the beginning, I have to use svn for doing "official" (svn) MFCs. Local MFCs via git always stay local. P.S. I am looking for a distributed solution (mercurial, bazaar?) that won't take away what I have with git, but would correctly work with svn mergeinfo. -- Andriy Gapon From ken at mthelicon.com Mon Jul 27 20:18:30 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Jul 27 20:18:36 2009 Subject: Fatal trap 12 ever since r195851 on AMD64 Message-ID: <200907272118.22188.ken@mthelicon.com> Hello Current, I dont know if there is a current issue with other systems or if it is localized to me, but ever since > r195914 I am getting a fatal trap on boot. The process is always in the swapper and is always a 12. System is AMD64 Core2-Quad, 4 Gigs, gptzfsboot from a mirror with zraid's mounted for /usr, /usr/home, etc.. Is anyone else seeing this as well? FreeBSD 8.0-BETA2 #137 r195914: Mon Jul 27 19:10:17 BST 2009 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805c482d stack pointer = 0x28:0xffffffff81076c90 frame pointer = 0x28:0xffffffff81076cc0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 Uptime: 1s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort Peg From ken at mthelicon.com Mon Jul 27 20:23:44 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Jul 27 20:23:56 2009 Subject: Fatal trap 12 ever since r195851 on AMD64 In-Reply-To: <200907272118.22188.ken@mthelicon.com> References: <200907272118.22188.ken@mthelicon.com> Message-ID: <200907272123.36633.ken@mthelicon.com> ACK! Sorry.. I messed up the revision number in the message body... On Monday 27 July 2009 21:18:22 Pegasus Mc Cleaft wrote: > I dont know if there is a current issue with other systems or if it is > localized to me, but ever since > r195914 I am getting a fatal trap on ^r195815 Peg From ken at mthelicon.com Mon Jul 27 20:28:17 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Jul 27 20:28:41 2009 Subject: Fatal trap 12 ever since r195851 on AMD64 In-Reply-To: <200907272123.36633.ken@mthelicon.com> References: <200907272118.22188.ken@mthelicon.com> <200907272123.36633.ken@mthelicon.com> Message-ID: <200907272128.01928.ken@mthelicon.com> Crud! Just shoot me! I'm very sorry about this.. Typing to fast and not checking.. On Monday 27 July 2009 21:23:36 Pegasus Mc Cleaft wrote: > ACK! Sorry.. I messed up the revision number in the message body... > > On Monday 27 July 2009 21:18:22 Pegasus Mc Cleaft wrote: > > I dont know if there is a current issue with other systems or if it is > > localized to me, but ever since > r195914 I am getting a fatal trap on > > ^r195815 ^r195851 (triple checked this time) From ken at mthelicon.com Mon Jul 27 20:28:17 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Jul 27 20:28:42 2009 Subject: Fatal trap 12 ever since r195851 on AMD64 In-Reply-To: <200907272123.36633.ken@mthelicon.com> References: <200907272118.22188.ken@mthelicon.com> <200907272123.36633.ken@mthelicon.com> Message-ID: <200907272128.01928.ken@mthelicon.com> Crud! Just shoot me! I'm very sorry about this.. Typing to fast and not checking.. On Monday 27 July 2009 21:23:36 Pegasus Mc Cleaft wrote: > ACK! Sorry.. I messed up the revision number in the message body... > > On Monday 27 July 2009 21:18:22 Pegasus Mc Cleaft wrote: > > I dont know if there is a current issue with other systems or if it is > > localized to me, but ever since > r195914 I am getting a fatal trap on > > ^r195815 ^r195851 (triple checked this time) From delphij at delphij.net Mon Jul 27 21:59:44 2009 From: delphij at delphij.net (Xin LI) Date: Mon Jul 27 21:59:51 2009 Subject: bsd.lib.mk question In-Reply-To: <4A6C1508.7020309@kovesdan.org> References: <4A6C1508.7020309@kovesdan.org> Message-ID: <4A6E2301.8080308@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, G?bor K?vesd?n wrote: > Hi, > > I wonder if there's a conventional way of building _only_ shared > libraries using bsd.lib.mk. At default, it builds static, shared and > profiled libraries, which is a waste of time because I only need shared > libraries, which I use as on-demand loadable modules. Adjusting _LIBS > after the inclusion of bsd.lib.mk doesn't help and there are no knobs to > control the behaviour. What should I do? If you define LIB= (or, not define it at all), and define both SHLIB and SHLIB_MAJOR, then only shared library is being built and installed. Example: LIB= SHLIB= test SHLIB_MAJOR= 0 Would build libtest.so.0, but no libtest.a nor libtest_p.a. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpuIwEACgkQi+vbBBjt66C50gCgul420W4siZi3VBA2ZnHxNz4J UesAoMIoSzqF0rE6TzvZ5/D0vyjbTc71 =Y5xW -----END PGP SIGNATURE----- From dougb at FreeBSD.org Tue Jul 28 02:42:17 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jul 28 02:42:24 2009 Subject: dynamic and static DNS in the samie name server In-Reply-To: <4A47E2B3.8040103@gmail.com> References: <4A47CC07.1080506@gmail.com> <20090628170140.7169d64b@bhuda.mired.org> <4A47E2B3.8040103@gmail.com> Message-ID: On Sun, 28 Jun 2009, Aryeh M. Friedman wrote: > Thanks for attempting to help me find the right place to post but in my > experience -questions@ tends to be about "standard" usage not "non-standard" > usage questions thus I asked here... yes I am using BIND (the base system > one) Actually you're both wrong. :) If this were a FreeBSD question then -questions would indeed have been the right list, but it's actually a BIND question which means it belongs on bind-users@isc.org. Good luck, Doug From fullermd at over-yonder.net Tue Jul 28 06:08:23 2009 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Tue Jul 28 06:08:30 2009 Subject: distributed scm+freebsd svn? In-Reply-To: <4A6D7EBE.7080304@freebsd.org> References: <20090726231534.GI21885@elvis.mu.org> <4A6D7EBE.7080304@freebsd.org> Message-ID: <20090728054850.GB76759@over-yonder.net> On Mon, Jul 27, 2009 at 01:17:34PM +0300 I heard the voice of Andriy Gapon, and lo! it spake thus: > > P.S. I am looking for a distributed solution (mercurial, bazaar?) > that won't take away what I have with git, but would correctly work > with svn mergeinfo. I use bazaar, but I don't use the svn integration. AIUI, bzr-svn will _write_ mergeinfo records for merges it creates and pushes into svn, but I don't know whether it reads existing ones. And a great deal of the existing mergeinfo in the BSD repo will be for cherrypicked revs, which aren't recorded anyway, so I don't know how much it would really gain. Vendor branch imports, maybe, but MFC's are right out. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From simon at comsys.ntu-kpi.kiev.ua Tue Jul 28 16:33:00 2009 From: simon at comsys.ntu-kpi.kiev.ua (Andrey Simonenko) Date: Tue Jul 28 16:33:07 2009 Subject: vm_map_protect / pmap_protect Can't lower protection In-Reply-To: References: Message-ID: <20090728155538.GA77306@pm513-1.comsys.ntu-kpi.kiev.ua> Hello Andrew, On Mon, Jul 20, 2009 at 04:14:02PM +0100, Andrew Brampton wrote: > However, memguard_unguard doesn't work correctly. It first calls > vm_map_protect with a read-write flag. > vm_map_protect correctly updates the vm_map_entry, and then calls > pmap_protect to set the actual pte. > pmap_protect is lazy and notices that we are reducing the protection > on the page and therefore does nothing. It assumes that later that a > page fault will occur, call vm_fault, and then fix up the pte then. As I remember, pmap_protect() is used for removing permissions, it cannot be used (even in initial versions of pmap code) for lowering permissions. pmap_enter() can be used to lower permissions, this is even written in its comments. From yuri at rawbw.com Wed Jul 29 00:34:02 2009 From: yuri at rawbw.com (Yuri) Date: Wed Jul 29 00:34:23 2009 Subject: How to profile the disk io performed through mmaps? Message-ID: <4A6F98F7.2080304@rawbw.com> I have a file mmapped to memory area and partially modified this way. Is there a way to know what are the actual disk writes/reads done on the file in this scenario? Would kqueue events on file's vnode be triggered for mmapped writes? Yuri From stas at FreeBSD.org Wed Jul 29 08:49:47 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Jul 29 08:49:54 2009 Subject: How to profile the disk io performed through mmaps? In-Reply-To: <4A6F98F7.2080304@rawbw.com> References: <4A6F98F7.2080304@rawbw.com> Message-ID: <20090729124939.0082e1d6.stas@FreeBSD.org> On Tue, 28 Jul 2009 17:33:59 -0700 Yuri mentioned: > I have a file mmapped to memory area and partially modified this way. > > Is there a way to know what are the actual disk writes/reads done on the > file in this scenario? > Would kqueue events on file's vnode be triggered for mmapped writes? Yes, it should be possible to monitor files written to via mmapped region with EVFILT_VNODE kevents. Please note, however, that changes to mmapped region may be propagated to the files not immediately depending on the region attributes. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090729/ba535075/attachment.pgp From yuri at rawbw.com Wed Jul 29 16:49:15 2009 From: yuri at rawbw.com (Yuri) Date: Wed Jul 29 16:49:22 2009 Subject: How to profile the disk io performed through mmaps? In-Reply-To: <20090729124939.0082e1d6.stas@FreeBSD.org> References: <4A6F98F7.2080304@rawbw.com> <20090729124939.0082e1d6.stas@FreeBSD.org> Message-ID: <4A707D88.7090703@rawbw.com> Stanislav Sedov wrote: > Yes, it should be possible to monitor files written to via mmapped region > with EVFILT_VNODE kevents. Please note, however, that changes to mmapped > region may be propagated to the files not immediately depending on the > region attributes. > But is there any command line utility that wraps kqueue functionality or I have to write my own code to do this? Yuri From oliver.pntr at gmail.com Wed Jul 29 17:23:19 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Wed Jul 29 17:23:26 2009 Subject: breaked kde3 Message-ID: <6101e8c40907290952p4bc65ebh4e039063130dfcf0@mail.gmail.com> [New Thread 0x800a020b0 (LWP 100411)] [Switching to Thread 0x800a020b0 (LWP 100411)] [KCrash handler] #6 0x000000080ca93364 in jpeg_CreateDecompress () from /usr/local/lib/compat/pkg/libjpeg.so.9 #7 0x0000000807744490 in read_jpeg_image () from /usr/local/lib/libqt-mt.so.3 #8 0x0000000807514890 in QImageIO::read () from /usr/local/lib/libqt-mt.so.3 #9 0x0000000807514fc3 in QImage::load () from /usr/local/lib/libqt-mt.so.3 #10 0x000000080d449ac1 in KBackgroundRenderer::doWallpaper () from /usr/local/lib/libkdeinit_kdesktop.so #11 0x000000080d44a6fb in KBackgroundRenderer::render () from /usr/local/lib/libkdeinit_kdesktop.so #12 0x000000080d44a9e5 in KBackgroundRenderer::qt_invoke () from /usr/local/lib/libkdeinit_kdesktop.so #13 0x000000080753a16e in QObject::activate_signal () from /usr/local/lib/libqt-mt.so.3 #14 0x000000080753adb9 in QObject::activate_signal () from /usr/local/lib/libqt-mt.so.3 #15 0x00000008075560ca in QTimer::event () from /usr/local/lib/libqt-mt.so.3 #16 0x00000008074ec149 in QApplication::internalNotify () from /usr/local/lib/libqt-mt.so.3 #17 0x00000008074ecb11 in QApplication::notify () from /usr/local/lib/libqt-mt.so.3 #18 0x000000080b5a62c6 in KApplication::notify () from /usr/local/lib/libkdecore.so.6 #19 0x00000008074e386f in QEventLoop::activateTimers () from /usr/local/lib/libqt-mt.so.3 #20 0x00000008074a992d in QEventLoop::processEvents () from /usr/local/lib/libqt-mt.so.3 #21 0x00000008074ff24a in QEventLoop::enterLoop () from /usr/local/lib/libqt-mt.so.3 #22 0x00000008074ff12e in QEventLoop::exec () from /usr/local/lib/libqt-mt.so.3 #23 0x000000080d40d0e1 in kdemain () from /usr/local/lib/libkdeinit_kdesktop.so #24 0x00000000004079d0 in execpath_avoid_loops () #25 0x00000000004081a7 in execpath_avoid_loops () #26 0x00000000004086f5 in execpath_avoid_loops () #27 0x0000000000408f2b in main () From mail at 0xabadba.be Wed Jul 29 19:29:49 2009 From: mail at 0xabadba.be (james toy) Date: Wed Jul 29 19:29:57 2009 Subject: distributed scm+freebsd svn? In-Reply-To: <20090728054850.GB76759@over-yonder.net> References: <20090726231534.GI21885@elvis.mu.org> <4A6D7EBE.7080304@freebsd.org> <20090728054850.GB76759@over-yonder.net> Message-ID: <61c92c7d0907291204g730020d6jb7237e7db2b9aa79@mail.gmail.com> Hello, I think the most important thing (other than compatibility) is that you use something that you work well with. Sure a lot of these VCS systems have advantages over the other; however, space is cheap -- git packs vs. mercurials way of packing is a minor detail compared to how useful the vcs is to you. That said I've used git, hg, and svn for freebsd development and use them extensively all over. In fact I've just finished a port of hg and hg-git (allows you to use hg to maintain a git repository) and find that its a very nice way to control all of my repositories with one program. I think the only real way to do development that you plan to try to merge is with freebsd-subversion; however, I'm sure there are people with varying views of this sentiment. Both git and hg have svn integration, so it really is up to you -- and if some functionality is missing -- you can always add it ;) have a good day and respectfully, james++ On Tue, Jul 28, 2009 at 01:48, Matthew D. Fuller wrote: > On Mon, Jul 27, 2009 at 01:17:34PM +0300 I heard the voice of > Andriy Gapon, and lo! it spake thus: >> >> P.S. I am looking for a distributed solution (mercurial, bazaar?) >> that won't take away what I have with git, but would correctly work >> with svn mergeinfo. > > I use bazaar, but I don't use the svn integration. ?AIUI, bzr-svn will > _write_ mergeinfo records for merges it creates and pushes into svn, > but I don't know whether it reads existing ones. ?And a great deal of > the existing mergeinfo in the BSD repo will be for cherrypicked revs, > which aren't recorded anyway, so I don't know how much it would really > gain. ?Vendor branch imports, maybe, but MFC's are right out. > > > -- > Matthew Fuller ? ? (MF4839) ? | ?fullermd@over-yonder.net > Systems/Network Administrator | ?http://www.over-yonder.net/~fullermd/ > ? ? ? ? ? On the Internet, nobody can hear you scream. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From stas at FreeBSD.org Wed Jul 29 20:05:10 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Jul 29 20:05:17 2009 Subject: How to profile the disk io performed through mmaps? In-Reply-To: <4A707D88.7090703@rawbw.com> References: <4A6F98F7.2080304@rawbw.com> <20090729124939.0082e1d6.stas@FreeBSD.org> <4A707D88.7090703@rawbw.com> Message-ID: <20090730000609.c9a1bea2.stas@FreeBSD.org> On Wed, 29 Jul 2009 09:49:12 -0700 Yuri mentioned: > Stanislav Sedov wrote: > > Yes, it should be possible to monitor files written to via mmapped region > > with EVFILT_VNODE kevents. Please note, however, that changes to mmapped > > region may be propagated to the files not immediately depending on the > > region attributes. > > > > > But is there any command line utility that wraps kqueue functionality or > I have > to write my own code to do this? > I'm not sure, but FAM should be able to detect these. gamin, for instance, uses kqueue to monitor events. You may be willing to try it. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090729/7234713f/attachment.pgp From yuri at rawbw.com Wed Jul 29 20:39:20 2009 From: yuri at rawbw.com (Yuri) Date: Wed Jul 29 20:39:27 2009 Subject: How to profile the disk io performed through mmaps? In-Reply-To: <20090729124939.0082e1d6.stas@FreeBSD.org> References: <4A6F98F7.2080304@rawbw.com> <20090729124939.0082e1d6.stas@FreeBSD.org> Message-ID: <4A70B375.1050900@rawbw.com> Stanislav Sedov wrote: > Yes, it should be possible to monitor files written to via mmapped region > with EVFILT_VNODE kevents. Please note, however, that changes to mmapped > region may be propagated to the files not immediately depending on the > region attributes. > From kqueue(2) I don't see how to get details (offsets/sizes) of write/extend events on the file. When I ask filter EVFILT_VNODE to monitor events NOTE_EXTEND and NOTE_WRITE kevent returns when any of them occur and it even ors NOTE_EXTEND and NOTE_WRITE flags in the output kevent structure. It gives no further details. So my question is largely open: how to monitor actual reads/writes on the file? Yuri