gmane.os.freebsd.architechture

Re: [patch] halt/reboot/shutdown cleanup

Willem Jan Withagen — 2012-05-22T14:50:06

I used these as obvious examples, but there are much more....
But that would be stealing the thread.

--WjW


_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: [patch] halt/reboot/shutdown cleanup

Peter Jeremy — 2012-05-21T20:53:26

[My vote on the halt/reboot/shutdown issue is that halt(8) & reboot(8)
should just be wrappers around reboot(2) and shutdown(8) should clean
up and run the rc.d shutdown scripts - but maybe I'm showing my age]

On 2012-May-20 23:23:24 +0200, Willem Jan Withagen <wjw< at >digiware.nl> wrote:

You can control much of that via /etc/periodic.conf - see
/etc/defaults/periodic.conf for details.


You probably still have a non-empty /etc/dumpdates.  Unfortunately,
you can't separately control the "df -h" and "dump W" output[1] but
an empty /etc/dumpdates will reduce it to one line.

[1] I think we're getting to the point where 400.status-disks should
    be split into 2.  dump(8) is becoming increasingly less relevant.

Re: Prefaulting for i/o buffers

Konstantin Belousov — 2012-05-21T10:45:18

I am reviving the thread.

Since the original publication of the patch, it got quite intensive reviews
and testing from several people, which I appreciate very much. The tagline
for the commit would include
Reviewed by:attilio, mdf, pjd, rmacklem (nfs client bits)
Tested by:pho, flo, Gustau P?rez <gperez entel upc edu>

The latest version of the patch is at
http://people.freebsd.org/~kib/misc/vm1.13.patch

The main change comparing with the previous publically discussed version
is the handling of the user buffers after vm_fault_quick_hold_pages(). I
did uiomove() over the region in the previous patch, but apparently
VM does not guarantee that corresponding pte entries are not removed,
or writeable access is kept. So new version of the patch uses
uiomove_fromphys() to avoid touching the usermode buffer, and operates
on the hold pages. I shall note that the issue was never observed in
real life.

This requires trivial modifications of the filesystem code, namely
the replacement of uiomove() with new helper

Re: [patch] halt/reboot/shutdown cleanup

Willem Jan Withagen — 2012-05-20T21:23:24

Well count me as one.

Although my strongest peave withs this is in the periodical scripts
which are too talkative for my taste.

eg. I haven't used dump in 10 years, but still my reports have dump
lines in them.

--WjW


_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: headers that use "struct bintime"

Bruce Evans — 2012-05-19T22:15:22


Not when it is not even used.


The POSIX.1-1990 support may be unimportant, but is the easiest part
of visibility limiting, since POSIX.1-1990 is a subset of everything
(except pure STDC (C90) which is even smaller).  __BSD_VISIBLE ifdefs
support it automatically for all FreeBSD extensions that are not in
any version of POSIX.  It's the ifdefs for later POSIX versions that
are more complicated, or would be if they all existed.  <sys> now has
- only 195 lines matching _VISIBLE
-       33 of these are in cdefs.h just to define all the visibility macros
-      117 of the remaining the others match __BSD_VISIBLE
- only  45 others (mainly with __POSIX_VISIBLE and __XSI_VISIBLE
- a whole 7 of these 45 match 1993 and a whole 14 of the 45 match 2001.
   POSIX grew from ~356 pages in 1990 to 3600 pages in 2001 (d7.pdf
   draft; it now covers utilities).  The new and changed interfaces can't
   be expressed by 7+14 ifdefs.  After 2001, it only grew to 3790 pages
   in a 2007 draft.  FreeBSD doesn't have any ifdefs

Re: headers that use "struct bintime"

Poul-Henning Kamp — 2012-05-19T18:56:05

In message <C876701D-6E4A-403F-A07D-52B45DD4E96C< at >bsdimp.com>, Warner Losh write
s:


That was not my impression, but I may be wrong on that.

Re: headers that use "struct bintime"

Warner Losh — 2012-05-19T18:50:24

On May 19, 2012, at 12:30 PM, Poul-Henning Kamp wrote:


Doesn't __BSD_VISIBLE do just that?

Warner


_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: headers that use "struct bintime"

Poul-Henning Kamp — 2012-05-19T18:30:49



I think at this time, we can either religiously stick to POSIX
and become irellevant with it, or we can develop our APIs to
become useful and desirable, and have a chance to survive.

Strictly 1980-compatible APIs will not gain FreeBSD 10+ any
new users.

Re: headers that use "struct bintime"

Bruce Evans — 2012-05-19T15:39:39


Not permitted.

Exposing struct bintime also exposes its internal pollution (see below).

sys/time.h is still massively polluted in other ways:

% #ifndef _SYS_TIME_H_
% #define _SYS_TIME_H_
% 
% #include <sys/_timeval.h>
% #include <sys/types.h>

Not permitted in POSIX.1, at least in the 2001 version (except all _t
names from here are permitted).  Only (all of the) pollution from
including <sys/select.h> is permitted.

% #include <sys/timespec.h>

This only gives the undocumented pollution TIMESPEC_TO_TIMEVAL() and
TIMEVAL_TO_TIMESPEC() (only under __BSD_VISIBLE).

% 
% struct timezone {
% inttz_minuteswest;/* minutes west of Greenwich */
% inttz_dsttime;/* type of dst correction */
% };
% #defineDST_NONE0/* not on dst */
% #defineDST_USA1/* USA style dst */
% #defineDST_AUST2/* Australian style dst */
% #defineDST_WET3/* Western European dst */
% #defineDST_MET4/* Middle European dst */
% #defineDST_EET5/* Eastern European dst */
% #defineDST_CAN6/* Canada */

This compati

Re: headers that use "struct bintime"

Poul-Henning Kamp — 2012-05-19T13:52:36

In message <20120519134005.GJ2358< at >deviant.kiev.zoral.com.ua>, Konstantin Belous
ov writes:


I think this is the best/right way to go.

Re: headers that use "struct bintime"

Konstantin Belousov — 2012-05-19T13:40:05

Note that all headers you listed are kernel headers, and kernel is exposed
to the whole namespace. I suspect that no headers are supposed to be used
by usermode among the list.

headers that use "struct bintime"

Robert Millan — 2012-05-19T13:33:03

"struct bintime" is enabled only by __BSD_VISIBLE. However, there are
a few headers that use "struct bintime" without __BSD_VISIBLE:

sys/arm/include/cpu.h
sys/dev/iscsi/initiator/iscsivar.h
sys/geom/journal/g_journal.h
sys/sys/dtrace_bsd.h
sys/sys/devicestat.h
sys/sys/timeet.h
sys/sys/bio.h
sys/opencrypto/cryptodev.h

Should the definitions that use "struct bintime" be __BSD_VISIBLE too?
 Or maybe "struct bintime" be defined unconditionally?

Or perhaps we could have "struct __bintime" and use that for system headers?

Re: Allow small amount of memory be mlock()'ed by unprivilegedprocess?

David Schultz — 2012-05-18T15:23:59

Two other points about this:

  - Each process already requires a number of wired pages in the
    kernel, so adding a few more in userland shouldn't be a big deal.

  - There are plenty of ways for an unprivileged user to wedge the
    system if they really try.

ISTR alc commenting on a similar proposal years ago; I think at the
time we didn't have appropriate accounting limits or something.
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: Allow small amount of memory be mlock()'ed by unprivileged process?

Bruce Evans — 2012-05-17T09:59:28


Products of limits are too large to actually be useful as limits in
most cases.  RLIMIT_NPROC usually gives the same limit as maxprocperuid.
E.g., on 2 very different systems I have handy both are 5547.  Then
the open file limit is 11095 on the smaller system (1GB RAM) and 3000
on the larger system (2GB RAM).  The product of 5507 and 11095 is > 58M.
There is no way the data structures for that many files can fit in 1GB
RAM.  So the limit is enough for normal operation but is useless for
defending against fork bombs.

Even if you have a small limit on the number of pages per user and a
small number of users, the product may be large, and vm needs to reserve
this number of pages so that it doesn't run out when doing more-critical
operations.  It might be able to preserve its reservations
(v_free_reserved, v_pageout_fre_min and v_interrupt_free_min) by reducing
the limit on the number of locked pages for each user and all users when
under pressure, but then unprivileged pages that have already grabbed and
loc

Re: [patch] halt/reboot/shutdown cleanup

Bruce Evans — 2012-05-17T09:25:13



Right, they can't be renamed without breaking things.

Please use the unix newline character.


Their bevaviour with the same options also can't be changed without
breaking things.


Quick, let's rename cp to COPY and del to DELETE.


Do you mean reinventing them from FreeBSD?  fastboot and fasthalt are
still standard in FreeBSD, but they have been reduced to hard links to
reboot.  They don't even change the action of reboot(8).  No one knows
about them of course (not even to the extent of noticing that they are
in reboot's man page), so reboot is used directly.

In FreeBSD-1 and 4.4BSD-Lite, they were shell scripts that copied
/dev/null to /fastboot and then invoked reboot and halt, respectively.
halt(8) has also been reduced to a hard link to reboot, but now it
changes the action of reboot.  It is misimplemented by making its
action depend on the program name but not providing an equivalent
option.


In FreeBSD, the whole point of fastboot was to suppress fsck.  It was
otherwise equivalent to reboot (bu

Re: Allow small amount of memory be mlock()'ed by unprivileged process?

Christoph Hellwig — 2012-05-17T05:54:25

Linux has added a RLIMIT_MEMLOCK opcode for setrlimit that allows
controlling the amount of memory users can lock down, with a default
of a single page for unprivilegued processes.

_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: [patch] halt/reboot/shutdown cleanup

Doug Barton — 2012-05-17T05:28:41

No problem. The pop culture version of "seriously?" is not what I
intended, but I can certainly see how you could have taken it that way.


I'm glad that we're converging on something useful.


Honestly, people coming over from Linux is on my RADAR. We're in a
situation now where the vast majority of our new users are going to be
coming from that world because they start their exposure to Unix with a
Linux desktop. I'm *not* saying that we need to gratuitously do things
the Linux way, but I am saying that we need to think more carefully
about being user friendly in a world where most of our users are not
historical BSD'ers.


At various times in the past I've proposed this exact solution. To be
honest I haven't analyzed Jilles' patches in detail because I didn't
want to wast time if there was no way they would go in. I'll give them
another look now.


I don't like the alias route as the default solution because it's too
easily circumvented, which would lead to even more user confusion. I dig
the SunOS vibe

Re: Allow small amount of memory be mlock()'ed by unprivilegedprocess?

Artem Belevich — 2012-05-16T23:10:27

Shouldn't RLIMIT_NPROC already limit the damage?

--Artem
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: Allow small amount of memory be mlock()'ed by unprivilegedprocess?

Eitan Adler — 2012-05-16T22:36:18

<quote>+ possibly limiting the number of pages per user, à la
maxprocperuid.</quote>

Re: Allow small amount of memory be mlock()'ed by unprivilegedprocess?

Adrian Chadd — 2012-05-16T22:32:40

.. what's to stop a fork() bomb from grabbing all pages?



Adrian
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

References to non-existent block devices

Peter Jeremy — 2012-05-16T21:37:08

I've noticed that although block devices were removed from FreeBSD
quite some time ago, there are still lots of references to them in man
pages and comments.  I've raised docs/167832 to basically change these
references to "disk devices".  I would appreciate a few more eyes
having a look over my suggested changes.