Re: [RFC] how to get the size of a malloc(9) block ?
jb jb.1234abcd at gmail.com writes: ... So far, the options could be as follows: - realloc_flags(p, s, option) where option is one or a combination (where appropriate) of: REALLOCF_ANY- default (move or no-move; regular realloc()) Actually, the REALLOCF_ANY flag is not needed to be able to call default behavior, like in realloc_flags(p, s). REALLOCF_NO_MOVE- no-move REALLOCF_ELASTIC- combined with REALLOCF_NO_MOVE REALLOCF_FORCE - combined with REALLOCF_NO_MOVE REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its derivatives like REALLOCF_ELASTIC, etc So, the REALLOCF_FALLBACK_ANY could be just renamed to REALLOCF_DEFAULT. This way we reduced the number of option tags to four :-) jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
dt71 at gmx.com writes: So new flags could be [1]: - realloc_flags(p, s, REALLOCF_NO_MOVE) ... - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC) ... For this, there could be a REALLOCF_FORCE flag In case of realloc_flags() failing the request, to avoid unnecessary followups with regular realloc() when desired, we should include an option like REALLOCF_FALLBACK_ANY that would allow to fallback on the regular realloc() logic, in one call. In addition, because I have an impression that realloc_flags() may have a future as a replacement for regular realloc() and we should aim for it, we should include an option like REALLOCF_ANY for that purpose. So far, the options could be as follows: - realloc_flags(p, s, option) where option is one or a combination (where appropriate) of: REALLOCF_ANY- default (move or no-move; regular realloc()) REALLOCF_NO_MOVE- no-move REALLOCF_ELASTIC- combined with REALLOCF_NO_MOVE REALLOCF_FORCE - combined with REALLOCF_NO_MOVE REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its derivatives like REALLOCF_ELASTIC, etc jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
Luigi Rizzo rizzo at iet.unipi.it writes: ... So far, the options could be as follows: - realloc_flags(p, s, option) where option is one or a combination (where appropriate) of: REALLOCF_ANY- default (move or no-move; regular realloc()) REALLOCF_NO_MOVE- no-move REALLOCF_ELASTIC- combined with REALLOCF_NO_MOVE REALLOCF_FORCE - combined with REALLOCF_NO_MOVE REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its derivatives like REALLOCF_ELASTIC, etc just five ? for a (quote) clean, safe and maintainable API, I'd probably also add a few more, such as REALLOCF_ALWAYS to trigger bugs on bad assumptions in the code, REALLOCF_I_AM_FEELING_LUCKY for the newbies, and REALLOCF_REAL_PROGRAMMERS_NEVER_DO_THAT_I_WILL_PANIC for skilled folks. ... These are more or less part of current implementation of realloc() :-) But seriously, the new API takes advantage of current logic - the no-move is already implemented as part of default. It will not (and should not) interfere with current implementation-specific details; it will just be smarter and useful thru its options by asking specific requests, some of which could be already be partially satisified now (think of that extra, unused allocated space, if present), thus giving a programmer more power in one call. Adding some if-else logic and perhaps limited code restructuring will yield a really powerful, functional API. Some of the hidden bugs in current realloc() co, if any, will be discovered during testing of new implementation (which will be more specific and thus less forgiving). Think of it as being presented with a chance to become part of history, as a co-creator of a new-and-improved memory management function, admittedly being many OS' and libraries' Achilles' heel :-) jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
Daniel Nebdal dnebdal at gmail.com writes: ... That could alternatively be solved by having an if I ask for N bytes right now, how large would the block be - API that doesn't promise too much. Call it something like malloc_suggest_size(size_t minsize) , and make the description something like ... return the largest number of bytes that would not allocate a larger block of memory than the provided minsize, in the current memory situation, plus some veiled threats about not using this value to do anything fancy with pointers to already-allocated memory. Yeap. It is like asking teenagers to be abstinent ... http://www.youtube.com/watch?v=SWlbN2b1PGg Good luck ! jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
dt71 at gmx.com writes: ... It appears that it's not possible to make a proper API with malloc_usable_size() included, at least when multi-threading is involved (ie., in the modern world). However, it is still useful to create an API that supports the following cases: ... Well, this is a step forward toward achieving a well defined API for memory reallocation. But can we arrive at this goal without consideration for leaked implementation details via malloc_usable_size() co ? We want to get rid of that leak and associated hacks. We want to induce reallocation function to do the right thing thru one API call with clear and smart options. If it does 90% of what we would ideally want, then the job is done. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
dt71 at gmx.com writes: ... So new flags could be [1]: - realloc_flags(p, s, REALLOCF_NO_MOVE): Resize object p, without moving it, to size s. With this restriction, when requesting more memory, and the specified amount isn't available, don't do anything (when requesting less memory, always succeed). - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC): Resize object p, without moving it, to size s. With this restriction, when requesting more memory, and the specified amount isn't available, reserve as much as possible (when requesting less memory, always succeed). ... The realloc_flags(), having different behavior from realloc(), should state what happens if: If the pointer is a null pointer, the function does not change anything. If the new size is zero, the function does not change anything. If the new size is the same as the old size, the function does not change anything. The return values have to be reviewed also. The function returns: - a pointer to the object specifid on entry - a null pointer if the object could not be modified - a null pointer if there was insufficient free memory available to extend the size of the object Reference to realloc(): http://www.cplusplus.com/reference/cstdlib/realloc/ jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
Luigi Rizzo rizzo at iet.unipi.it writes: ... There is a difference between applications peeking into implementation details that should be hidden, and providing instead limited and specific information through a well defined API. ... Right. If you want to improve memory management, that is, have the system (kernel or user space) handle memory reallocation intelligently and transparently to the user, then aim at a well defined API: - reallocate with no copy, which means new space appended (taking into account *usable size*, a hidden-to-user implementation detail), if possible - otherwise fail, and let the user decide about reallocation with copy or allocation of a new space The malloc_usable_size() is a hack. The extra space allocated or not due to fragmentation, alignment, etc, is an internal by-product, irrelevant to original memory alloc request, and it should not be leaked, also because its details may change in future API implementations. So, these memory allocation functions leaking implementation details, and the two derived functions, ksize() and malloc_usable_size() (and other derivatives like malloc_size() in Mac OS X), are a violations of a clean, safe, and maintainable API. Note that malloc_usable_size() is a GNU C Library extension, not part of Single UNIX Specification. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
Luigi Rizzo rizzo at iet.unipi.it writes: ... If you want to improve memory management, that is, have the system (kernel or user space) handle memory reallocation intelligently and transparently to the user, then aim at a well defined API: - reallocate with no copy, which means new space appended (taking into account *usable size*, a hidden-to-user implementation detail), if possible - otherwise fail, and let the user decide about reallocation with copy or allocation of a new space i respectfully disagree :) but am not pushing to add ksize. Just note that both mine and your well defined API leak details: yours is (A) I may be overallocating but won't tell you how much; mine is (B) I may be overallocating and here is exactly how much. Now if I may make a comparison with going shopping, I'd rather hear the final price from the seller (case B), than having to guess by repeated trial and error, which is what case A leads to if i really want to figure out. ... This is not necessarily true - I omitted the details of reallocation implementation on purpose. From the caller's point of view, if it requested allocation of memory size, then that's what it wanted in the first place. If it got it, then there is no other info needed. Next, if the caller came to the conclusion that more would be needed, then it should ask for memory reallocation, trusting that the system will do it in the most efficient way. If the caller wants to influence that process, then proper option(s) are needed in reallocation API, e.g.: - with no copy - with copy That means one call with options, with a specific (wanted by user) result. Of course, thinking thru the options (default, mutual exclusion, etc) is an important process and subject to RFC. A user-empowering API. No magic, no hacks. So, how about Request-for-Enhancement to GNU C lib, and the ugly hacks will disappear quickly. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
Luigi Rizzo rizzo at iet.unipi.it writes: in porting some linux kernel code to FreeBSD we stumbled upon ksize(), which returns the actual size of a kmalloc() block. We could easily implement it as the first part of realloc(9) -- see kern/kern_malloc.c Would it make sense to add this to the malloc(9) API ? The userspace equivalent seems to be malloc_usable_size(3) which according to the manpage appeared in FreeBSD 7.0 Hi, The implementation of ksize() depends on (has non-standard behavior across) architectures, memory allocators, page sizes, C libs, etc. It means, ksize() exports its implementation details to the caller, and this disqualifies it, regardless whether in kernel or user spaces. This leads to dangerous and conflicting assertions: malloc_usable_size(3) on Linux: NOTES The value returned by malloc_usable_size() may be greater than the requested size of the allocation because of alignment and minimum size constraints. Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation. The main use of this function is for debugging and introspection. Other sources: ... The caller may use this additional memory, even though a smaller amount of memory was initially specified with the kmalloc call. ... This is hair-raising: http://lwn.net/Articles/319686/ Result ? The same code works here, but may not elsewhere. It follows, you should remove malloc_usable_size() from user space instead. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
Luigi Rizzo rizzo at iet.unipi.it writes: ... But I don't understand why you find ksize()/malloc_usable_size() dangerous. ... The original crime is commited when *usable size* (an implementation detail) is exported (leaked) to the caller. To be blunt, when a caller requests memory of certain size, and its request is satisfied, then it is not its business to learn details beyond that (and they should not be offered as well). The API should be sanitized, in kernel and user space. Otherwise, all kind of charlatans will try to play hair-raising games with it. If the caller wants to track the *requested size* programmatically, it is its business to do it and it can be done very easily. Some of these guys got it perfectly right: http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memory-allocated-to-the-pointer-without-searching-fo jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: brigding between two interfaces
Yasir hussan kolyasir at gmail.com writes: Hi, i am little bit weak in networking concept, i have two network interfaces usb0 and eth0, eth0 is connected to a static ip, which works perfectly fine, now i want that usb0 should be able to access static ip which is connected to eth0, http://www.freebsd.org/doc/handbook/network-bridging.html jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
10-CURRENT - LOR (lock order reversal)
Hi, these represent machine lockups, if not false positives. http://www.freebsd.org/cgi/query-pr.cgi?pr=182139cat= jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
10-alpha1 iso does not boot
Hi, FreeBSD-10.0-ALPHA1-i386-disc1.iso Verified checksum. I can not boot from CD-RW at all - it does not seem to be recognized. Anybody else has similar experience ? jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-alpha1 iso does not boot
Thomas Mueller mueller6724 at bellsouth.net writes: FreeBSD-10.0-ALPHA1-i386-disc1.iso Verified checksum. I can not boot from CD-RW at all - it does not seem to be recognized. Anybody else has similar experience ? jb Is your CD-RW not recognized even before it tries to boot? Is your disc1.iso burned to CD or DVD? Is the drive CD or DVD? If you can't get disc1.iso to work, you might try memstick.img and dd to USB stick. Tom I burned it to cd-rw again and this time boot process started, but it got stuck at: CD Loader 1.2 ... FreeBSD/x86 bootstrap loader, Revision 1.1 (root@...) \ jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-alpha1 iso does not boot
Glen Barber gjb at FreeBSD.org writes: ... Can you try the 20130907 -CURRENT snapshot here? http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/i386/10.0/ Glen OK. That worked out. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: prompt w/ uid 0 for cshrc
Eitan Adler lists at eitanadler.com writes: On 18 November 2012 18:44, Mateusz Guzik mjguzik at gmail.com wrote: Just take user name from id -nu. While that does provide the $user value I want, id is in /usr/bin/ which may not be mounted. /rescue/id jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
jb jb.1234abcd at gmail.com writes: ... There are memory management subsystem considerations against utilizing tmpfs (memory + swap) for /tmp: ... - Out-of-Memory (OOM) killer Due to it, on heavy loaded systems processes dying on memory pressure. - Pterodactyl The next MM subsystem feature. An urban legend ... The final frontier ... jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
jb jb.1234abcd at gmail.com writes: ... Chuck Burns brea...@gmail.com 1:01 AM (16 hours ago) My experiences with using tmpfs as /tmp -- It works fine. until it doesn't. I've had mountpoints run out of space, checked df and the mountpoint had been reduced to something like 2 MiB TOTAL, with nothing free.. on a machine with 8GiB RAM.. however, rebooting restores the mount to around 2GiB.. but then after some heavy usage, the mountpoint once again starts shrinking in size. I've noticed this behavior in multiple versions of FreeBSD, and switched to using md instead, with no more issues. I'm not willing to use tmpfs until it's proven to be more stable than it was when I was using it. --- Chuck, plz check your posting to the list (I received it, which I reposted here). jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Rainer Duffner rainer at ultra-secure.de writes: Am Sun, 1 Apr 2012 09:40:25 -0400 schrieb Gary Palmer gpalmer at freebsd.org: Other than catching software that mistakenly assumes /tmp and/or /var/run is persistent, what are the CLEAR advantages for changing the default? It's my understanding it improves performance in cases where lots of files are created and deleted in /tmp (and/or /var/tmp - sometimes software hard-codes these locations...). ... OTOH, on new installs, a TMPFS could be used automatically if memory = 4GB. ... There are memory management subsystem considerations against utilizing tmpfs (memory + swap) for /tmp: - only part of the program needs to be in the memory for execution Delayed and hidden demand for memory. - demand paging Bring a page from swap into memory only when it is needed. Delayed and hidden demand for memory. - Copy-on-Write Initial sharing of memory by processes. Delayed and hidden demand for memory. - thrashing Excessive in/out swap utilization. Very high page-fault rate - low CPU utilization - OS thinks it can schedule more tasks - another process added for execution - memory overcommit Physical memory overcommit resulting in paging; swap space pre-reservation Due to it, on heavy loaded systems processes dying on memory pressure. - Out-of-Memory (OOM) killer Due to it, on heavy loaded systems processes dying on memory pressure. There is a potential for overlapping and multiplying effects from the above and possibly other factors. If somebody wants it, despite all dangers to efficiency and stability of their system, let them make that choice. After all, what real pros are known for is that they know why and how to customize their systems for a task. To offer it as a default setup is not called for, regardless of memory plus swap sizes. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
O. Hartmann ohartman at zedat.fu-berlin.de writes: Am 03/29/12 18:14, schrieb David Wolfskill: On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. ... ... Linux is using TMPFS filesystems a lot for these purposes. How do they overcome restrictions of the size or not flloding RAM and/or swap? ... Read it before you make up your mind (there are real issues to consider): http://fedoraproject.org/wiki/Features/var-run-tmpfs http://fedoraproject.org/wiki/Talk:Features/var-run-tmpfs jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
deeptech71 at gmail.com writes: ... One of those reasons people stick/stuck with BSD is that we don't go and change this stuff so quickly. Yes, it would be a total of ~20 years before we finally decided to switch to using TMPFS for /tmp. ... According to TMPFS(5) BUGS The tmpfs kernel implementation is currently considered as an experimen- tal feature. Some file system mount time options are not well supported. Perhaps there is a reason to not push experimental things on users ? Btw, I hope Quotas is supported by tmpfs. I do not know about you, but I feel differently about /tmp even as part of / fs beeing bombed by mega-size files, and /tmp as /tmpfs (main memory plus swap) getting full or even reaching some preset value and having some priority job or its data or caches being swapped. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Updating the tuning man page
break the system components). /etc/rc.conf: powerd_flags=-n hadp performance_cx_lowest=C2 economy_cx_lowest=C2 performance_cpu_freq=HIGH Test: - - measure dev.cpu.0.freq - measure dev.cpu.0.freq during compilation - measure dev.cpu.0.freq while disk quiet 'top' to report near 100% idle - measure dev.cpu.0.freq after few seconds jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Double free() in libc or gdb ?
Alexandre Martins alexandre.martins at netasq.com writes: ... first.c: ... second.c ... main.c ... while(42) How do you exit that loop ? ... Compilation and execution : gcc -shared -O0 -g second.c -o second.so gcc -shared -O0 -g first.c -o libfirst.so gcc -O0 -g toto.c -lfirst -L. -o test export LD_LIBRARY_PATH=$PWD gdb ./test ... What is your toto.c (source code) ? What about your main.c in compilation ? jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SU+J and fsck problem ?
Adrian Chadd adrian at freebsd.org writes: Please file a PR and put as much debugging output as you can. ... Because this is a case of clean shutdown and oing on purpose to single user mode to see how these hings behave, I assume I can go and try again and collect similar info. But, is there any debugging method I as a user can utilize to collect specific info that could aid devs ? jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SU+J and fsck problem ?
Hi, FB9.0-RELEASE; no updates or recompilation. In multi-user mode: $ mount /dev/ada0s2a on / (ufs, local, journaled soft-updates) The fs was in normal state (no known problem, clean shutdown), Booted by choice in single-user mode. # mount /dev/ada0s2a on / (ufs, local, read-only) # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] y ** SU+J recovering /dev/ada0s2a ** Reading 33554432 byte journal from inode 4. RECOVER? [yn] y ** ... ** Processing journal entries. WRITE CHANGES? [yn] y ** 208 journal records in 13312 bytes for 50% utilization ** Freed 0 inodes (0 dirs) 6 blocks, and 0 frags. * FILE SYSTEM MARKED CLEAN # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] n ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=114700 (8 should be 0) CORRECT? [yn] n INCORRECT BLOCK COUNT I=196081 (32 should be 8) CORRECT? [yn] n INCORRECT BLOCK COUNT I=474381 (32 should be 8) CORRECT? [yn] n ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLOCK COUNTS(S) WRONG IN SUPERBLK SALVAGE? [yn] n SUMMARY INFORMATION BAD SALVAGE? [yn] n BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] n 266075 files, 939314 used, 1896628 free (2724 frags, 236738 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED DIRTY * * FILE SYSTEM WAS MODIFIED * * PLEASE RERUN FSCK * # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] y ** SU+J recovering /dev/ada0s2a Journal timestamp does not match fs mount time ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=114700 (8 should be 0) CORRECT? [yn] y INCORRECT BLOCK COUNT I=196081 (32 should be 8) CORRECT? [yn] y INCORRECT BLOCK COUNT I=474381 (32 should be 8) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLOCK COUNTS(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * # Summary: 1. # fsck -F ## recovery done with J 2. # fsck -F ## no recovery; fs marked dirty; time stamp modified Why during this step there were incorrect block counts reported if the fs was recovered and marked clean in step 1 ? Despite the fact that choice of no recovery was made, the fs was marked dirty (based on false assumption above ?, and time stamp ?) 3. # fsck -F ## forced skipped Journal Same question as in step 2, based on which it accepted the choice of recovery ... Note: after step 2: 1896628 free and 2724 frags in 266075 files, 939314 used, 1896620 free (2724 frags, 236738 blocks, ... after step 3: 1896629 free and 2725 frags in 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, ... Questions: - is the fsck working properly with SU+J fs ? Note: fsck(8) -F ... -B ... It is recommended that you perform foreground fsck on your systems periodically and whenever you encounter file-system-related panics. - would the fs as after step 1, and steps 1-3 or 1,3 be considered recovered: - structurally ? - identical ?, does it matter ? - integrally ? Any comments before I file a PR# ? jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: revisiting tunables under Safe Mode menu option
Devin Teske devin.teske at fisglobal.com writes: ... So I would welcome discussions involving development of something better (and am willing to help). ... Not exactly sure what service safemode start should do (BSD doesn't have the same concept of runlevels as Linux does; so it's not exactly intuitive to think we could go from multi-user mode *into* safe mode). But service safemode status would be interesting. Interestingly, it would perhaps be nice if service safemode stop brought the system back to fully usable without need for reboot (something Windows doesn't offer). I looked around the Internet and collected some sound bites: - Safe Mode - it forces a check of startup (root) partition. - you have access to only minimal number of basic files and drivers (mouse, monitor, keyboard, mass storage, base video, fonts, default system services, and no network connections). If your computer does not start successfully using Safe Mode, you might need to use the Safe Mode with Root Shell feature to repair your system. - it disables all startup items and login items - it has to delete (and eventually recreate) any shared caches (dynamic loader, dynamic libraries, etc) - it enables boot logging The boot log is useful in determining the exact cause of system startup problems. Log all drivers and services that were loaded (or not loaded) by the system to a file. - what about remote fs (NFS, etc) ? - it helps you diagnose problems. If a symptom does not reappear when you start in safe mode, you can eliminate the default settings and minimum device drivers as possible causes. If a newly added device or a changed driver is causing problems, you can use safe mode to remove the device or reverse the change. The same with newly installed packages. - enabled debugging mode It may be preconfigured for debugging mode with info to be sent across a serial cable to another computer that is running a debugger. - enabled networking mode (optional) This to allow remote safe mode. - startable from a local or remote terminal, on a command line. In case of a remote startup it would require networking mode enabled. - boot verbosity mode (full, regular, minimal, none) - logging verbosity mode (full, regular, minimal, none) - option to return to boot menu (loader) - option to reboot - Safe Mode with Root Shell Like regular Safe Mode with boot into root shell (like Single User Mode, with configurable root password requirement). This mode is particularly useful if you need to repair your system by copying a file from a CD-ROM to your hard drive, or if you need to reconfigure a service that is preventing your computer from starting properly. This functionality is indeed similar to Single User Mode, but after further considerations it may be different under Safe Mode. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: negative group permissions?
Jason Hellenthal jhellenthal at dataix.net writes:
...
The file should not be executable, according to its purpose.
So the lpr.c should be changed from
if ((fd = open(buf, O_RDWR|O_CREAT, 0661)) 0) {
...
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165533
...
Above I see your .seq file created 0641 so not only do you have a
negative permission on the file you are also missing a bit ;).
0641 ? Are you sure ?
...
I attempted to search around for the history of 661 on .seq but cannot
find any at the moment. E_LACKINGSLEEP
Check the PR filing again - I appended a relevant comment.
Also, Linux distros (if you can swallow it ...) also disallowed it due to sec
reason, but in a clumsy way by making sure the exec permission is turned off
in a package install script.
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: negative group permissions?
Jason Hellenthal jhellenthal at dataix.net writes: On Wed, Feb 29, 2012 at 08:54:20AM +, jb wrote: 0641 ? Are you sure ? Not at all ;) Checking negative group permissions: 70834 -rw-rx 1 root daemon 4 Feb 21 12:54:02 2012 /var/spool/output/lpd/.seq OK. You referred to his installation state. That's another question - perhaps one more reason to get rid of that exec' bit for security. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: negative group permissions?
Anton Shterenlikht mexas at bristol.ac.uk writes: ... To the best of my knowledge the security warning started to appear recently. For the previous 2 years or so I haven't seen it. Now, I didn't modify the default security scripts, nor the lpd system. The file is created with this permissions because the OS created it like this, not me. I've no idea why my file is 0641 instead of 0661. I would suggest (if you can) that you change the .seq permissions to 0664 and watch what happens to it - the purpose is to narrow down who/what changed its mode. Some history. logs. and some ad hoc watch script would do it. So, given that the lpr.c hasn't changed for years, perhaps the periodic scripts have, and what was earlier considered fine now is considered serious enough to issue a security warning. In any case, it seems either lpr.c needs to be changed, or if 0661 is necessary, then the periodic sripts need to be changed to ignore this file. The periodic script is OK. Here is the author's view: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-October/033256.html jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: negative group permissions?
jb jb.1234abcd at gmail.com writes: ... I would suggest (if you can) that you change the .seq permissions to 0664 and watch what happens to it - the purpose is to narrow down who/what changed its mode. Some history. logs. and some ad hoc watch script would do it. Take a look at notify feature (file, dir, event). http://www.freebsd.org/cgi/ports.cgi?query=notifystype=all jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: negative group permissions?
Ian Lepore freebsd at damnhippie.dyndns.org writes: ... It's not a directory or executable file in the first place, so making it executable for everyone except the owner and group is not some sort of subtle security trick, it's just meaningless. ... Is it meaningless ? Example: # cat /var/spool/output/lpd/.seq #! /usr/local/bin/bash touch /tmp/jb-test-`echo $$` # ls -al /var/spool/output/lpd/.seq -rw-rx 1 root daemon 54 Feb 29 17:05 /var/spool/output/lpd/.seq # /var/spool/output/lpd/.seq # # ls /tmp/jb* /tmp/jb-test-61789 # chmod 0640 /var/spool/output/lpd/.seq # ls -al /var/spool/output/lpd/.seq -rw-r- 1 root daemon 52 Feb 29 17:11 /var/spool/output/lpd/.seq # /var/spool/output/lpd/.seq su: /var/spool/output/lpd/.seq: Permission denied # jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: negative group permissions?
Ian Lepore freebsd at damnhippie.dyndns.org writes: ... Again, the problem here seems to be the use of 0661 in the lpr program, not the idea of negative permissions, not the new scan for the use of negative permissions. This will go away after the fix below is applied. It's just an old bug in an old program which used to be harmless and now is mostly harmless. Instead of trying to fix it by causing the new scan to ignore it, why don't we fix it by fixing the program? (I'd submit a patch but it's a 1-character change -- it's not clear to me a patch would be easier for a commiter to handle than just finding and changing the only occurrance of 0661 in lpr.c.) Yes, that's what we suggested, in PR filed as well. Let's change lpr.c so that the .seq create permission is 0664. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: negative group permissions?
Anton Shterenlikht mexas at bristol.ac.uk writes:
This was discussed in questions@ with no resolution.
Anybody here can advise further?
...
Regarding file .seq or .SEQ
It is an intermediate-processing (run-time) lockfile found in various spool
dirs and their sub-dirs, like
/var/spool/cron/
/at,
/lpd, etc.
It is used to save job# by the respective programs (cron, at, etc).
You can find a ref to .SEQ in file at.c in at port sources.
I did not see ref to .seq in lpr or cron port sources.
The periodic security check
/etc/periodic/security/110.neggrpperm
checks for risque condition like
! -perm +010 -and -perm +001
The file should not be executable, according to its purpose.
So the lpr.c should be changed from
if ((fd = open(buf, O_RDWR|O_CREAT, 0661)) 0) {
to
if ((fd = open(buf, O_RDWR|O_CREAT, 0660)) 0) {
File a bug report.
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
