svn commit: r321783 - head/usr.bin/calendar/calendars

2017-07-31 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Mon Jul 31 13:08:47 2017
New Revision: 321783
URL: https://svnweb.freebsd.org/changeset/base/321783

Log:
  add myself to calendar.freebsd

Modified:
  head/usr.bin/calendar/calendars/calendar.freebsd

Modified: head/usr.bin/calendar/calendars/calendar.freebsd
==
--- head/usr.bin/calendar/calendars/calendar.freebsdMon Jul 31 12:09:24 
2017(r321782)
+++ head/usr.bin/calendar/calendars/calendar.freebsdMon Jul 31 13:08:47 
2017(r321783)
@@ -94,6 +94,7 @@
 03/07  Michael P. Pritchard <m...@freebsd.org> born in Los Angeles, 
California, United States, 1964
 03/07  Giorgos Keramidas <keram...@freebsd.org> born in Athens, Greece, 1976
 03/10  Andreas Klemm <andr...@freebsd.org> born in Duesseldorf, 
Nordrhein-Westfalen, Germany, 1963
+03/10  Nikolai Lifanov <lifa...@freebsd.org> born in Moscow, Russian 
Federation, 1989
 03/11  Soeren Straarup <xr...@freebsd.org> born in Andst, Denmark, 1978
 03/12  Greg Lewis <gle...@freebsd.org> born in Adelaide, South Australia, 
Australia, 1969
 03/13  Alexander Leidinger <netch...@freebsd.org> born in Neunkirchen, 
Saarland, Germany, 1976
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318313 - head/libexec/rtld-elf

2017-05-15 Thread Nikolai Lifanov 
On 05/15/2017 15:52, Konstantin Belousov wrote:
> On Mon, May 15, 2017 at 07:42:23PM +, Alexey Dokuchaev wrote:
>> On Mon, May 15, 2017 at 10:40:49PM +0300, Konstantin Belousov wrote:
>>> On Mon, May 15, 2017 at 03:37:42PM -0400, Nikolai Lifanov wrote:
>>>> On 05/15/2017 15:36, Alexey Dokuchaev wrote:
>>>>> ...
>>>>> Would this now allow executing binaries (with or without +x bit) from
>>>>> filesystems mounted with -o noexec?
>>>>
>>>> No:
>>>>
>>>> # zfs create -o mountpoint=/mnt -o exec=off tank/TEST
>>>> # cp /bin/sh /mnt/
>>>> # /mnt/sh
>>>> /mnt/sh: Permission denied.
>>>> # /libexec/ld-elf.so.1 /mnt/sh
>>>> /mnt/sh: mmap of data failed: Permission denied
>>>
>>> This is due to
>>> r313967 | kib | 2017-02-19 22:51:04 +0200 (Sun, 19 Feb 2017) | 24 lines
>>> Apply noexec mount option for mmap(PROT_EXEC).
>>
>> Nice, good to know that.
> 
> [Replying to random mail in thread]
> 
> I tried this on an up to date latest Fedora installation:
> [kostik@sandy ~]$ cp /bin/ls /tmp
> [kostik@sandy ~]$ chmod a-x /tmp/ls
> [kostik@sandy ~]$ /lib64/ld-linux-x86-64.so.2  /tmp/ls
> Dropbox  intel  tmp  work
> 
> I am not sure about one detail, the /tmp/ls file has some security context
> on it, but I do not believe that it may affect the outcome of the experiment.
> Please correct me if I am wrong.
> 


This is because /tmp is exec. On Linux it does the same thing:

# mount -t tmpfs none -o noexec,mode=1777 /mnt
# cp /bin/bash /mnt/
# /lib64/ld-linux-x86-64.so.2 /mnt/bash
/mnt/bash: error while loading shared libraries: /mnt/bash: failed to
map segment from shared object: Operation not permitted

- Nikolai Lifanov



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318313 - head/libexec/rtld-elf

2017-05-15 Thread Nikolai Lifanov 
On 05/15/2017 15:36, Alexey Dokuchaev wrote:
> On Mon, May 15, 2017 at 10:25:29PM +0300, Konstantin Belousov wrote:
>> On Mon, May 15, 2017 at 01:08:55PM -0600, Ian Lepore wrote:
>>> Well, for example, it seems like it would allow anyone to execute a
>>> binary even if the sysadmin had set it to -x specifically to prevent
>>> people from running it.
>>
>> The direct mode does not (and cannot) honor set{u,g}id modes of the
>> executable, so any binary run this way would only exercise the existing
>> power of the user which did it.
>>
>> The most advanced explanation that I was given in private was among
>> the lines: "if you have an environment where users can upload content
>> to a shared server, but have no access to chmod(2), no compilers, no
>> scripting languages, etc." The person then admitted that (s)he does not
>> consider it as an actual concern.
> 
> Would this now allow executing binaries (with or without +x bit) from
> filesystems mounted with -o noexec?
> 
> ./danfe

No:

# zfs create -o mountpoint=/mnt -o exec=off tank/TEST
# cp /bin/sh /mnt/
# /mnt/sh
/mnt/sh: Permission denied.
# /libexec/ld-elf.so.1 /mnt/sh
/mnt/sh: mmap of data failed: Permission denied

- Nikolai Lifanov



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318313 - head/libexec/rtld-elf

2017-05-15 Thread Nikolai Lifanov 
On 05/15/2017 15:32, Bryan Drewery wrote:
> On 5/15/2017 12:29 PM, Konstantin Belousov wrote:
>> On Mon, May 15, 2017 at 12:25:20PM -0700, Bryan Drewery wrote:
>>> On 5/15/2017 12:00 PM, Konstantin Belousov wrote:
>>>> On Mon, May 15, 2017 at 06:52:36PM +, Alexey Dokuchaev wrote:
>>>>> On Mon, May 15, 2017 at 06:48:58PM +, Konstantin Belousov wrote:
>>>>>> New Revision: 318313
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/318313
>>>>>>
>>>>>> Log:
>>>>>>   Make ld-elf.so.1 directly executable.
>>>>>
>>>>> Does it mean that old Linux' trick of /lib/ld-linux.so.2 /bin/chmod +x
>>>>> /bin/chmod would now be possible on FreeBSD as well?
>>>> Yes.
>>>>
>>>>> Does this have any security implications?
>>>> What do you mean ?
>>>>
>>>
>>> I think for 3rd-party distributions it may be a problem. At the very
>>> least it needs to be communicated clearly in release notes or UPDATING.
>>>
>>> Consider a downstream vendor who has support for signed binary
>>> executions.  If rtld allows a backdoor around exec(2) to run an unsigned
>>> binary, that could be a problem for them.  It is on them to add support
>>> to exec(2) to validate the special case of execing rtld with an
>>> argument, or to just disable the feature in rtld from this commit.
>>
>> Note the undocumented O_VERIFY flag in open(2) from the patch.
>> This is very vendor-ish addition to request veriexec (?).
>>
> 
> Ah nice.
> 


Note, this already does the right thing with noexec filesystems:
# zfs create -o mountpoint=/mnt -o exec=off tank/TEST
# cp /bin/sh /mnt/
# /mnt/sh
/mnt/sh: Permission denied.
# /libexec/ld-elf.so.1 /mnt/sh
/mnt/sh: mmap of data failed: Permission denied

- Nikolai Lifanov



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318313 - head/libexec/rtld-elf

2017-05-15 Thread Nikolai Lifanov 
On 05/15/2017 15:18, Jonathan Anderson wrote:
> On 15 May 2017, at 16:44, Jonathan Anderson wrote:
> 
>> You can already execute "non-executable" binaries using the `exec`
>> shell built-in:
>>
>> ```
>> $ cp /bin/sh .
>> $ chmod -x sh
>> $ exec sh
>> ```
> 
> Er, oops: I ought to have said, you can execute non-executable binaries
> by copying and marking them `+x`:
> 
> ```
> $ cp /bin/sh .
> $ chmod +x sh
> $ ./sh
> ```
> 
> (please ignore the bit about `exec`, that's from another mental thread)
> 
> 
> Jon

And the default install doesn't mount /tmp noexec ...

- Nikolai Lifanov



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318313 - head/libexec/rtld-elf

2017-05-15 Thread Nikolai Lifanov 
On 05/15/2017 14:52, Alexey Dokuchaev wrote:
> On Mon, May 15, 2017 at 06:48:58PM +, Konstantin Belousov wrote:
>> New Revision: 318313
>> URL: https://svnweb.freebsd.org/changeset/base/318313
>>
>> Log:
>>   Make ld-elf.so.1 directly executable.
> 
> Does it mean that old Linux' trick of /lib/ld-linux.so.2 /bin/chmod +x
> /bin/chmod would now be possible on FreeBSD as well?  Does this have
> any security implications?
> 
> ./danfe

This is a use case for fixing accidentally hosed /bin/chmod binary and
not some sort of an escalation thing. You will need to be root to do
this. Likewise, with working chmod binary, you should be able to mark
binaries with write access executable.

- Nikolai Lifanov



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

2017-05-13 Thread Nikolai Lifanov 
On 05/13/2017 13:21, Ngie Cooper (yaneurabeya) wrote:
> Even ansible/chef/puppet would have to bake the configuration removal logic 
> into its template files, which seems like a pain for folks (and the same 
> logic would need to be implemented multiple times instead of once).

Having to template one .conf file couples not necessarily related config
modules together and it's *a lot* more performant to conditionally
install and remove config snippets in .d/ than to expand a template.

The separation matters when separate people write separate configuration
modules and the performance matters when deciding on frequency of config
runs.

- Nikolai



signature.asc
Description: OpenPGP digital signature

svn commit: r312352 - stable/10/sys/dev/kbd

2017-01-17 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Tue Jan 17 22:02:22 2017
New Revision: 312352
URL: https://svnweb.freebsd.org/changeset/base/312352

Log:
  MFC r311650
  
  Restore priority value for OGIO_KEYMAP
  
  PR:   206678
  Submitted by: ect...@gmail.com
  Reviewed by:  cem
  Approved by:  cem, matthew (mentor)
  MFC after:1 week
  Differential Revision:https://reviews.freebsd.org/D5095

Modified:
  stable/10/sys/dev/kbd/kbd.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/dev/kbd/kbd.c
==
--- stable/10/sys/dev/kbd/kbd.c Tue Jan 17 22:01:33 2017(r312351)
+++ stable/10/sys/dev/kbd/kbd.c Tue Jan 17 22:02:22 2017(r312352)
@@ -884,7 +884,7 @@ genkbd_commonioctl(keyboard_t *kbd, u_lo
omapp->key[i].spcl = mapp->key[i].spcl;
omapp->key[i].flgs = mapp->key[i].flgs;
}
-   return (0);
+   break;
case PIO_KEYMAP:/* set keyboard translation table */
case OPIO_KEYMAP:   /* set keyboard translation table (compat) */
 #ifndef KBD_DISABLE_KEYMAP_LOAD
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r312351 - stable/11/sys/dev/kbd

2017-01-17 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Tue Jan 17 22:01:33 2017
New Revision: 312351
URL: https://svnweb.freebsd.org/changeset/base/312351

Log:
  MFC r311650
  
  Restore priority value for OGIO_KEYMAP
  
  PR:   206678
  Submitted by: ect...@gmail.com
  Reviewed by:  cem
  Approved by:  cem, matthew (mentor)
  MFC after:1 week
  Differential Revision:https://reviews.freebsd.org/D5095

Modified:
  stable/11/sys/dev/kbd/kbd.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/dev/kbd/kbd.c
==
--- stable/11/sys/dev/kbd/kbd.c Tue Jan 17 21:12:21 2017(r312350)
+++ stable/11/sys/dev/kbd/kbd.c Tue Jan 17 22:01:33 2017(r312351)
@@ -884,7 +884,7 @@ genkbd_commonioctl(keyboard_t *kbd, u_lo
omapp->key[i].spcl = mapp->key[i].spcl;
omapp->key[i].flgs = mapp->key[i].flgs;
}
-   return (0);
+   break;
case PIO_KEYMAP:/* set keyboard translation table */
case OPIO_KEYMAP:   /* set keyboard translation table (compat) */
 #ifndef KBD_DISABLE_KEYMAP_LOAD
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r311650 - head/sys/dev/kbd

2017-01-07 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Sat Jan  7 15:58:57 2017
New Revision: 311650
URL: https://svnweb.freebsd.org/changeset/base/311650

Log:
  Restore priority value for OGIO_KEYMAP
  
  PR:   206678
  Submitted by: ect...@gmail.com
  Reviewed by:  cem
  Approved by:  cem, matthew (mentor)
  MFC after:1 week
  Differential Revision:https://reviews.freebsd.org/D5095

Modified:
  head/sys/dev/kbd/kbd.c

Modified: head/sys/dev/kbd/kbd.c
==
--- head/sys/dev/kbd/kbd.c  Sat Jan  7 15:57:12 2017(r311649)
+++ head/sys/dev/kbd/kbd.c  Sat Jan  7 15:58:57 2017(r311650)
@@ -884,7 +884,7 @@ genkbd_commonioctl(keyboard_t *kbd, u_lo
omapp->key[i].spcl = mapp->key[i].spcl;
omapp->key[i].flgs = mapp->key[i].flgs;
}
-   return (0);
+   break;
case PIO_KEYMAP:/* set keyboard translation table */
case OPIO_KEYMAP:   /* set keyboard translation table (compat) */
 #ifndef KBD_DISABLE_KEYMAP_LOAD
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r310288 - stable/10

2016-12-19 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Mon Dec 19 19:39:02 2016
New Revision: 310288
URL: https://svnweb.freebsd.org/changeset/base/310288

Log:
  MFC r310160
  
  retain cc.4.gz man page for Chelsio T6 NICs
  
  This man page was removed in r225583 when cc.4 was renamed to mod_cc.4
  With reintroduction of cc.4 "make installworld; make delete-old" was
  no longer convergent.
  
  Reviewed by:  matthew
  Approved by:  jhb (implicit), matthew (mentor)
  Differential Revision:https://reviews.freebsd.org/D8829

Modified:
  stable/10/ObsoleteFiles.inc
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/ObsoleteFiles.inc
==
--- stable/10/ObsoleteFiles.inc Mon Dec 19 19:37:55 2016(r310287)
+++ stable/10/ObsoleteFiles.inc Mon Dec 19 19:39:02 2016(r310288)
@@ -937,7 +937,6 @@ OLD_FILES+=usr/lib32/libftpio_p.a
 OLD_FILES+=usr/include/ftpio.h
 OLD_FILES+=usr/share/man/man3/ftpio.3.gz
 # 20110915: rename congestion control manpages
-OLD_FILES+=usr/share/man/man4/cc.4.gz
 OLD_FILES+=usr/share/man/man9/cc.9.gz
 # 20110831: atomic page flags operations
 OLD_FILES+=usr/share/man/man9/vm_page_flag.9.gz
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r310287 - stable/11

2016-12-19 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Mon Dec 19 19:37:55 2016
New Revision: 310287
URL: https://svnweb.freebsd.org/changeset/base/310287

Log:
  MFC r310160
  
  retain cc.4.gz man page for Chelsio T6 NICs
  
  This man page was removed in r225583 when cc.4 was renamed to mod_cc.4
  With reintroduction of cc.4 "make installworld; make delete-old" was
  no longer convergent.
  
  Reviewed by:  matthew
  Approved by:  jhb (implicit), matthew (mentor)
  Differential Revision:https://reviews.freebsd.org/D8828

Modified:
  stable/11/ObsoleteFiles.inc
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/ObsoleteFiles.inc
==
--- stable/11/ObsoleteFiles.inc Mon Dec 19 19:21:28 2016(r310286)
+++ stable/11/ObsoleteFiles.inc Mon Dec 19 19:37:55 2016(r310287)
@@ -2777,7 +2777,6 @@ OLD_FILES+=usr/lib32/libftpio_p.a
 OLD_FILES+=usr/include/ftpio.h
 OLD_FILES+=usr/share/man/man3/ftpio.3.gz
 # 20110915: rename congestion control manpages
-OLD_FILES+=usr/share/man/man4/cc.4.gz
 OLD_FILES+=usr/share/man/man9/cc.9.gz
 # 20110831: atomic page flags operations
 OLD_FILES+=usr/share/man/man9/vm_page_flag.9.gz
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r310160 - head

2016-12-16 Thread Nikolai Lifanov 
On 12/16/2016 15:12, John Baldwin wrote:
> On Friday, December 16, 2016 05:44:57 PM Nikolai Lifanov wrote:
>> Author: lifanov (ports committer)
>> Date: Fri Dec 16 17:44:56 2016
>> New Revision: 310160
>> URL: https://svnweb.freebsd.org/changeset/base/310160
>>
>> Log:
>>   retain cc.4.gz man page for Chelsio T6 NICs
>>   
>>   This man page was removed in r225583 when cc.4 was renamed to mod_cc.4
>>   With reintroduction of cc.4 "make installworld; make delete-old" was
>>   no longer convergent.
> 
> Please MFC to 10 and 11 since cc(4) is now present there as well.
> 

Makes sense, will do!

- Nikolai Lifanov




signature.asc
Description: OpenPGP digital signature

svn commit: r310160 - head

2016-12-16 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Fri Dec 16 17:44:56 2016
New Revision: 310160
URL: https://svnweb.freebsd.org/changeset/base/310160

Log:
  retain cc.4.gz man page for Chelsio T6 NICs
  
  This man page was removed in r225583 when cc.4 was renamed to mod_cc.4
  With reintroduction of cc.4 "make installworld; make delete-old" was
  no longer convergent.
  
  Reported by:  Trond Endrestøl
  Reviewed by:  np, matthew
  Approved by:  np, matthew (mentor)
  Differential Revision:https://reviews.freebsd.org/D8816

Modified:
  head/ObsoleteFiles.inc

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Fri Dec 16 17:41:20 2016(r310159)
+++ head/ObsoleteFiles.inc  Fri Dec 16 17:44:56 2016(r310160)
@@ -2939,7 +2939,6 @@ OLD_FILES+=usr/lib32/libftpio_p.a
 OLD_FILES+=usr/include/ftpio.h
 OLD_FILES+=usr/share/man/man3/ftpio.3.gz
 # 20110915: rename congestion control manpages
-OLD_FILES+=usr/share/man/man4/cc.4.gz
 OLD_FILES+=usr/share/man/man9/cc.9.gz
 # 20110831: atomic page flags operations
 OLD_FILES+=usr/share/man/man9/vm_page_flag.9.gz
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r310024 - head/share/misc

2016-12-13 Thread Nikolai Lifanov 
Author: lifanov (ports committer)
Date: Tue Dec 13 16:53:58 2016
New Revision: 310024
URL: https://svnweb.freebsd.org/changeset/base/310024

Log:
  add myself as a ports committer and update mentor/mentee relationship
  
  Reviewed by:  matthew
  Approved by:  matthew (mentor)
  Differential Revision:https://reviews.freebsd.org/D8774

Modified:
  head/share/misc/committers-ports.dot

Modified: head/share/misc/committers-ports.dot
==
--- head/share/misc/committers-ports.dotTue Dec 13 16:20:10 2016
(r310023)
+++ head/share/misc/committers-ports.dotTue Dec 13 16:53:58 2016
(r310024)
@@ -145,6 +145,7 @@ lawrance [label="Sam Lawrance\nlawrance@
 lbr [label="Lars Balker Rasmussen\n...@freebsd.org\n2006/04/30"]
 leeym [label="Yen-Ming Lee\nle...@freebsd.org\n2002/08/14"]
 lev [label="Lev Serebryakov\n...@freebsd.org\n2003/06/17"]
+lifanov [label="Nikolai Lifanov\nlifa...@freebsd.org\n2016/12/11"]
 linimon [label="Mark Linimon\nlini...@freebsd.org\n2003/10/23"]
 lioux [label="Mario Sergio Fujikawa Ferriera\nli...@freebsd.org\n2000/10/14"]
 lippe [label="Felippe de Meirelles Motta\nli...@freebsd.org\n2008/03/08"]
@@ -475,6 +476,8 @@ mat -> tcberner
 mat -> thierry
 mat -> woodsb02
 
+matthew -> lifanov
+
 mezz -> tmclaugh
 
 miwi -> amdmi3
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r301010 - in head/sys: cddl/contrib/opensolaris/common/zfs cddl/contrib/opensolaris/uts/common cddl/contrib/opensolaris/uts/common/fs/zfs cddl/contrib/opensolaris/uts/common/fs/zfs/sys

2016-05-31 Thread Nikolai Lifanov 
On 05/31/2016 03:28, Jan Beich wrote:
> Allan Jude  writes:
> 
>> Author: allanjude
>> Date: Tue May 31 04:12:14 2016
>> New Revision: 301010
>> URL: https://svnweb.freebsd.org/changeset/base/301010
>>
>> Log:
>>   Connect the SHA-512t256 and Skein hashing algorithms to ZFS
>>   
>>   Support for the new hashing algorithms in ZFS was introduced in r289422
>>   However it was disconnected because FreeBSD lacked implementations of
>>   SHA-512 (truncated to 256 bits), and Skein.
>>   
>>   These implementations were introduced in r300921 and r300966 respectively
>>   
>>   This commit connects them to ZFS and enabled these new checksum algorithms
>>   
>>   This new algorithms are not supported by the boot blocks, so do not use 
>> them
>>   on your root dataset if you boot from ZFS.
> 
> Can you document the feature and booting caveat in zpool-features(7) manpage?
> And Illumos seems to limit booting support to pools vs. datasets.
> 

+1. Also, zfs(8) needs to be updated.

>   Booting off of pools using skein is NOT supported -- any attempt to
>   enable skein on a root pool will fail with an error.
> 
> https://illumos.org/man/5/zpool-features
> 

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r296428 - head/sys/boot/common

2016-03-06 Thread Nikolai Lifanov 
On March 6, 2016 4:13:34 PM EST, Dimitry Andric <d...@freebsd.org> wrote:
>On 06 Mar 2016, at 20:57, Nikolai Lifanov <lifa...@mail.lifanov.com>
>wrote:
>> 
>> On 2016-03-06 11:17, Dimitry Andric wrote:
>>> On 06 Mar 2016, at 17:00, Oliver Pinter
><oliver.pin...@hardenedbsd.org> wrote:
>>>> On 3/6/16, Dimitry Andric <d...@freebsd.org> wrote:
>>>>> Author: dim
>>>>> Date: Sun Mar  6 15:57:43 2016
>>>>> New Revision: 296428
>>>>> URL: https://svnweb.freebsd.org/changeset/base/296428
>>>>> Log:
>>>>> Since kernel modules can now contain sections of type
>SHT_AMD64_UNWIND,
>>>>> the boot loader should not skip over these anymore while loading
>images.
>>>>> Otherwise the kernel can still panic when it doesn't find the
>.eh_frame
>>>>> section belonging to the .rela.eh_frame section.
>>>>> Unfortunately this will require installing boot loaders from
>sys/boot
>>>>> before attempting to boot with a new kernel.
>>>> Could you please add a note about this to UPDATING file?
>>> I am a bit torn on this, because normally we always tell people to
>>> install the kernel first, reboot, then run make installworld (which
>also
>>> installs the boot loaders).
>>> However, in this case, people might depend on their boot loader
>loading
>>> modules which are required to make the system boot at all.  So if
>they
>>> happened to forget updating their boot loader first, a panic might
>be
>>> the result.
>>> I wonder what a failsafe and acceptable upgrade scenario is, in this
>>> case.  Normally the procedure is something like:
>>>  make buildworld
>>>  make buildkernel (with KERNCONF=whatever, if needed)
>>>  make installkernel (again with KERNCONF, if needed)
>>>  reboot (to single user, but cheating is possible usually)
>>>  mergemaster -p
>>>  make installworld
>>> This could maybe be modified to:
>>>  make buildworld
>>>  make buildkernel (with KERNCONF=whatever, if needed)
>>>  make installkernel (again with KERNCONF, if needed)
>>>  make -C sys/boot install
>>>  reboot (to single user, but cheating is possible usually)
>>>  mergemaster -p
>>>  make installworld
>>> E.g. insert the step which installs the boot loaders just after (or
>>> before) the step which installs the kernel.
>>> Is something like this acceptable as a one-time workaround, or maybe
>it
>>> is better in general, in case we ever add other new features to the
>boot
>>> loaders?
>>> -Dimitry
>> 
>> In my opinion, boot *blocks* (boot1) should be updated seldomly and
>not on every install.
>> All (?) instances of not updating these resulting in a failed boot
>have an UPDATING
>> entry or a similar warning (like the one during "zpool upgrade").
>
>Well, each time you run make installworld, almost all the files in
>/boot
>(except for configuration) get reinstalled.  For e.g. mbr, boot1 and
>such, this has no consequences at all, until you install them into some
>partition using gpart, but changes to loader, loader.efi or zfsloader
>*will* affect the next startup.
>
>Per a suggestion from Kostik, maybe it would be nice to have a separate
>"make installboot" target, which installs just the components in /boot.
>This could then be used before or after "make installkernel".
>
>-Dimitry

The bootcode gets installed to boot, but deployed with gpart, cp, sliced in 
half and dd, etc. And that's to one or more partitions.
I don't think that a separate install target that just stages boot1 to /boot is 
valuable.


- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r296428 - head/sys/boot/common

2016-03-06 Thread Nikolai Lifanov 

On 2016-03-06 11:17, Dimitry Andric wrote:
On 06 Mar 2016, at 17:00, Oliver Pinter <oliver.pin...@hardenedbsd.org> 
wrote:


On 3/6/16, Dimitry Andric <d...@freebsd.org> wrote:

Author: dim
Date: Sun Mar  6 15:57:43 2016
New Revision: 296428
URL: https://svnweb.freebsd.org/changeset/base/296428

Log:
 Since kernel modules can now contain sections of type 
SHT_AMD64_UNWIND,
 the boot loader should not skip over these anymore while loading 
images.
 Otherwise the kernel can still panic when it doesn't find the 
.eh_frame

 section belonging to the .rela.eh_frame section.

 Unfortunately this will require installing boot loaders from 
sys/boot

 before attempting to boot with a new kernel.


Could you please add a note about this to UPDATING file?


I am a bit torn on this, because normally we always tell people to
install the kernel first, reboot, then run make installworld (which 
also

installs the boot loaders).

However, in this case, people might depend on their boot loader loading
modules which are required to make the system boot at all.  So if they
happened to forget updating their boot loader first, a panic might be
the result.

I wonder what a failsafe and acceptable upgrade scenario is, in this
case.  Normally the procedure is something like:

  make buildworld
  make buildkernel (with KERNCONF=whatever, if needed)
  make installkernel (again with KERNCONF, if needed)
  reboot (to single user, but cheating is possible usually)
  mergemaster -p
  make installworld

This could maybe be modified to:

  make buildworld
  make buildkernel (with KERNCONF=whatever, if needed)
  make installkernel (again with KERNCONF, if needed)
  make -C sys/boot install
  reboot (to single user, but cheating is possible usually)
  mergemaster -p
  make installworld

E.g. insert the step which installs the boot loaders just after (or
before) the step which installs the kernel.

Is something like this acceptable as a one-time workaround, or maybe it
is better in general, in case we ever add other new features to the 
boot

loaders?

-Dimitry


In my opinion, boot *blocks* (boot1) should be updated seldomly and not 
on every install.
All (?) instances of not updating these resulting in a failed boot have 
an UPDATING

entry or a similar warning (like the one during "zpool upgrade").

- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys

2016-01-19 Thread Nikolai Lifanov 
On 01/19/16 16:02, Nikolai Lifanov wrote:
> On 01/19/16 15:52, Kurt Lidl wrote:
>> On 1/19/16 1:55 PM, Alan Somers wrote:
>>> On Tue, Jan 19, 2016 at 10:00 AM, Alan Somers <asom...@freebsd.org>
>>> wrote:
>>>> Author: asomers
>>>> Date: Tue Jan 19 17:00:25 2016
>>>> New Revision: 294329
>>>> URL: https://svnweb.freebsd.org/changeset/base/294329
>>>>
>>>> Log:
>>>>Disallow zvol-backed ZFS pools
>>>>
>>>>Using zvols as backing devices for ZFS pools is fraught with
>>>> panics and
>>>>deadlocks. For example, attempting to online a missing device in the
>>>>presence of a zvol can cause a panic when vdev_geom tastes the
>>>> zvol.  Better
>>>>to completely disable vdev_geom from ever opening a zvol. The
>>>> solution
>>>>relies on setting a thread-local variable during vdev_geom_open, and
>>>>returning EOPNOTSUPP during zvol_open if that thread-local
>>>> variable is set.
>>>>
>>>>Remove the check for MUTEX_HELD(_state_lock) in zvol_open.
>>>> Its intent
>>>>was to prevent a recursive mutex acquisition panic. However, the
>>>> new check
>>>>for the thread-local variable also fixes that problem.
>>>>
>>>>Also, fix a panic in vdev_geom_taste_orphan. For an unknown
>>>> reason, this
>>>>function was set to panic. But it can occur that a device
>>>> disappears during
>>>>tasting, and it causes no problems to ignore this departure.
>>>>
>>>>Reviewed by:  delphij
>>>>MFC after:1 week
>>>>Relnotes: yes
>>>>Sponsored by: Spectra Logic Corp
>>>>Differential Revision:https://reviews.freebsd.org/D4986
>>>>
>>>> Modified:
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
>>>>
>>>> Modified:
>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>>
>>> Due to popular demand, I will conditionalize this behavior on a
>>> sysctl, and I won't MFC it.  The sysctl must default to off (ZFS on
>>> zvols not allowed) because having the ability to put pools on zvols
>>> can cause panics even for users who aren't using it.
>>
>> Thank you!
>>
>>> And let me clear up some confusion:
>>>
>>> 1) Having the ability to put a zpool on a zvol can cause panics and
>>> deadlocks, even if that ability is unused.
>>> 2) Putting a zpool atop a zvol causes unnecessary performance problems
>>> because there are two layers of COW involved, with all their software
>>> complexities.  This also applies to putting a zpool atop files on a
>>> ZFS filesystem.
>>> 3) A VM guest putting a zpool on its virtual disk, where the VM host
>>> backs that virtual disk with a zvol, will work fine.  That's the ideal
>>> use case for zvols.
>>> 3b) Using ZFS on both host and guest isn't ideal for performance, as
>>> described in item 2.  That's why I prefer to use UFS for VM guests.
>>
>> The patch as is does very much break the way some people do operations
>> on zvols.  My script that does virtual machine cloning via snapshots
>> of zvols containing zpools is currently broken due to this. (I upgraded
>> one of my dev hosts right after your commit, to verify the broken
>> behavior.)
>>
>> In my script, I boot an auto-install .iso into bhyve:
>>
>> bhyve -c 2 -m ${vmmem} -H -A -I -g 0 \
>> -s 0:0,hostbridge \
>> -s 1,lpc -l com1,stdio \
>> -s 2:0,virtio-net,${template_tap} \
>> -s 3:0,ahci-hd,"${zvol}" \
>> -s 4:0,ahci-cd,"${isofile}" \
>> ${vmname} || \
>> echo "trapped error exit from bhyve: $?"
>>
>> So, yes, the zpool gets created by the client VM.  Then on
>> the hypervisor host, the script imports that zpool and renames it,
>> so that I can have different pool names for all the client VMs.
>> This step now fails:
>>
>> + zpool import -R /virt/base -d /dev/zvol/zdata sys base
>> cannot i

Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys

2016-01-19 Thread Nikolai Lifanov 
On 01/19/16 15:52, Kurt Lidl wrote:
> On 1/19/16 1:55 PM, Alan Somers wrote:
>> On Tue, Jan 19, 2016 at 10:00 AM, Alan Somers 
>> wrote:
>>> Author: asomers
>>> Date: Tue Jan 19 17:00:25 2016
>>> New Revision: 294329
>>> URL: https://svnweb.freebsd.org/changeset/base/294329
>>>
>>> Log:
>>>Disallow zvol-backed ZFS pools
>>>
>>>Using zvols as backing devices for ZFS pools is fraught with
>>> panics and
>>>deadlocks. For example, attempting to online a missing device in the
>>>presence of a zvol can cause a panic when vdev_geom tastes the
>>> zvol.  Better
>>>to completely disable vdev_geom from ever opening a zvol. The
>>> solution
>>>relies on setting a thread-local variable during vdev_geom_open, and
>>>returning EOPNOTSUPP during zvol_open if that thread-local
>>> variable is set.
>>>
>>>Remove the check for MUTEX_HELD(_state_lock) in zvol_open.
>>> Its intent
>>>was to prevent a recursive mutex acquisition panic. However, the
>>> new check
>>>for the thread-local variable also fixes that problem.
>>>
>>>Also, fix a panic in vdev_geom_taste_orphan. For an unknown
>>> reason, this
>>>function was set to panic. But it can occur that a device
>>> disappears during
>>>tasting, and it causes no problems to ignore this departure.
>>>
>>>Reviewed by:  delphij
>>>MFC after:1 week
>>>Relnotes: yes
>>>Sponsored by: Spectra Logic Corp
>>>Differential Revision:https://reviews.freebsd.org/D4986
>>>
>>> Modified:
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
>>>
>>> Modified:
>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>
>> Due to popular demand, I will conditionalize this behavior on a
>> sysctl, and I won't MFC it.  The sysctl must default to off (ZFS on
>> zvols not allowed) because having the ability to put pools on zvols
>> can cause panics even for users who aren't using it.
> 
> Thank you!
> 
>> And let me clear up some confusion:
>>
>> 1) Having the ability to put a zpool on a zvol can cause panics and
>> deadlocks, even if that ability is unused.
>> 2) Putting a zpool atop a zvol causes unnecessary performance problems
>> because there are two layers of COW involved, with all their software
>> complexities.  This also applies to putting a zpool atop files on a
>> ZFS filesystem.
>> 3) A VM guest putting a zpool on its virtual disk, where the VM host
>> backs that virtual disk with a zvol, will work fine.  That's the ideal
>> use case for zvols.
>> 3b) Using ZFS on both host and guest isn't ideal for performance, as
>> described in item 2.  That's why I prefer to use UFS for VM guests.
> 
> The patch as is does very much break the way some people do operations
> on zvols.  My script that does virtual machine cloning via snapshots
> of zvols containing zpools is currently broken due to this. (I upgraded
> one of my dev hosts right after your commit, to verify the broken
> behavior.)
> 
> In my script, I boot an auto-install .iso into bhyve:
> 
> bhyve -c 2 -m ${vmmem} -H -A -I -g 0 \
> -s 0:0,hostbridge \
> -s 1,lpc -l com1,stdio \
> -s 2:0,virtio-net,${template_tap} \
> -s 3:0,ahci-hd,"${zvol}" \
> -s 4:0,ahci-cd,"${isofile}" \
> ${vmname} || \
> echo "trapped error exit from bhyve: $?"
> 
> So, yes, the zpool gets created by the client VM.  Then on
> the hypervisor host, the script imports that zpool and renames it,
> so that I can have different pool names for all the client VMs.
> This step now fails:
> 
> + zpool import -R /virt/base -d /dev/zvol/zdata sys base
> cannot import 'sys' as 'base': no such pool or dataset
> Destroy and re-create the pool from
> a backup source.
> 
> I import the clients' zpools after the zpools on them has
> been renamed, so the hypervisor host can manipulate the
> files directly.  It only disturbs a small amount of the
> disk blocks on each of the snapshots of the zvol to rename
> the zpools.
> 
> In this way, I can instantiate ~30 virtual machines from
> a custom install.iso image in less than 3 minutes.  And
> the bulk of that time is doing the installation from the
> custom install.iso into the first virtual machine.  The
> cloning of the zvols, and manipulation of the resulting
> filesystems is very fast.
> 

Can't you just set volmode=dev and use zfs clone?

> -Kurt
> 
> 
> 
> ___
> svn-src-h...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

___
svn-src-all@freebsd.org mailing list

Re: svn commit: r287227 - in head: lib/libstand share/mk sys/boot/efi sys/boot/ficl sys/boot/i386 sys/boot/libstand32 sys/boot/pc98 sys/boot/userboot/ficl sys/boot/userboot/libstand sys/boot/zfs

2015-08-28 Thread Nikolai Lifanov 
On 08/27/15 19:46, Warner Losh wrote:
 Author: imp
 Date: Thu Aug 27 23:46:42 2015
 New Revision: 287227
 URL: https://svnweb.freebsd.org/changeset/base/287227
 
 Log:
   Use CFLAGS_NO_SIMD in preference to varying lists of -mno- flags.
   Go ahead and defined -D_STANDALONE for all targets (only strictly
   needed for some architecture, but harmless on those it isn't required
   for). Also add -msoft-float to all architectures uniformly rather
   that higgley piggley like it is today.
   
   Differential Revision: https://reviews.freebsd.org/D3496
 
 Added:
   head/share/mk/bsd.stand.mk   (contents, props changed)
 Modified:
   head/lib/libstand/Makefile
   head/sys/boot/efi/Makefile.inc
   head/sys/boot/ficl/Makefile
   head/sys/boot/i386/Makefile.inc
   head/sys/boot/libstand32/Makefile
   head/sys/boot/pc98/Makefile.inc
   head/sys/boot/userboot/ficl/Makefile
   head/sys/boot/userboot/libstand/Makefile
   head/sys/boot/zfs/Makefile
 

Hi! I get this on amd64 after this commit:

--- sys.all__D ---
ld: i386:x86-64 architecture of input file
`/usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a(qdivrem.o)'
is incompatible with i386 output
*** [gptboot.out] Error code 1

- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r278450 - head/release

2015-02-09 Thread Nikolai Lifanov 

On 2015-02-09 05:46, Glen Barber wrote:

Author: gjb
Date: Mon Feb  9 10:46:39 2015
New Revision: 278450
URL: https://svnweb.freebsd.org/changeset/base/278450

Log:
  Revert r278445.

  I was going to use __FreeBSD_version to determine if
  xz(1) should be multi-threaded by default, but doing
  this will cause problems if/when the changes are merged
  from head.

  Sponsored by: The FreeBSD Foundation

Modified:
  head/release/Makefile

Modified: head/release/Makefile



Can you just X-MFC this with xz 5.2.0 import?
You can then refer to xz in OBJDIR to get this to work on older 
releases.


- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

2014-09-08 Thread Nikolai Lifanov 

On 2014-09-03 21:18, Steven Hartland wrote:

- Original Message - From: Andriy Gapon a...@freebsd.org



on 03/09/2014 23:22 Nikolai Lifanov said the following:

On 09/03/14 15:22, John Baldwin wrote:

On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:

On 09/03/14 04:09, Steven Hartland wrote:

I'm looking to MFC this change so wanted to check if
anyone had an final feedback / objections?

I know we currently have Alan's feedback on changing
the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
which sounds sensible but waiting Peter to comment on.

   Regards
   Steve


I have no technical input, but this change improves ARC usefulness 
for

me quite a bit. I would like to see the improvement in 10-STABLE.


Can you verify that the current 10-STABLE (as of today) with all the 
various pagedaemon fixes still has ARC issues for your workload?




It doesn't have any issues, but I noticed the improvement on CURRENT. 
I

observed that just after this change, my package builder is much more
likely to retain MFU and not evict useful things from there (the port
tree) after large builds.
However, I run a lot more 10.0-RELEASE than CURRENT and I would like 
to

see this improvement release-bound.

I would be happy to test this on 10-STABLE if you think that this is
relevant.



As noted before, unfortunately, this commit (plus its fixups) contains 
at least
two related but distinct changes.  So, to separate the wheat from the 
chaff,

could you please try to comment out the following block in
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, function 
arc_reclaim_needed:


   if (kmem_free_count()  zfs_arc_free_target) {
   DTRACE_PROBE2(arc__reclaim_freetarget, uint64_t,
   kmem_free_count(), uint64_t, zfs_arc_free_target);
   return (1);
   }

Alternatively, I think that the same effect can be achieved by setting 
sysctl

vfs.zfs.arc_free_target to the same value as vm.stats.vm.v_free_min.


Thats correct that would achieve the same thing.

It's interesting to me whether you would still see the better 
performance or if

that improvement would be undone.


Indeed that would be interesting, but we might find that its quite 
memory size

dependent given the scaling so confirming HW details would be nice too.

I'd also be interested to know who wins the free race between the VM 
and ARC

when using that value.

For those following this thread but not the review, I've added some 
additional

information there which you might be interested in:
https://reviews.freebsd.org/D702

   Regards
   Steve


I had time to re-test both the stock condition after the improvements 
and the condition in which 
vfs.zfs.arc_free_target=vm.stats.vm.v_free_min. It seems that MFU is 
more likely to be reduced in the second case.


- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

2014-09-04 Thread Nikolai Lifanov 
On 09/03/14 21:18, Steven Hartland wrote:
 
 - Original Message - From: Andriy Gapon a...@freebsd.org
 
 
 on 03/09/2014 23:22 Nikolai Lifanov said the following:
 On 09/03/14 15:22, John Baldwin wrote:
 On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
 On 09/03/14 04:09, Steven Hartland wrote:
 I'm looking to MFC this change so wanted to check if
 anyone had an final feedback / objections?

 I know we currently have Alan's feedback on changing
 the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
 which sounds sensible but waiting Peter to comment on.

Regards
Steve

 I have no technical input, but this change improves ARC usefulness for
 me quite a bit. I would like to see the improvement in 10-STABLE.

 Can you verify that the current 10-STABLE (as of today) with all the
 various pagedaemon fixes still has ARC issues for your workload?


 It doesn't have any issues, but I noticed the improvement on CURRENT. I
 observed that just after this change, my package builder is much more
 likely to retain MFU and not evict useful things from there (the port
 tree) after large builds.
 However, I run a lot more 10.0-RELEASE than CURRENT and I would like to
 see this improvement release-bound.

 I would be happy to test this on 10-STABLE if you think that this is
 relevant.


 As noted before, unfortunately, this commit (plus its fixups) contains
 at least
 two related but distinct changes.  So, to separate the wheat from the
 chaff,
 could you please try to comment out the following block in
 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, function
 arc_reclaim_needed:

if (kmem_free_count()  zfs_arc_free_target) {
DTRACE_PROBE2(arc__reclaim_freetarget, uint64_t,
kmem_free_count(), uint64_t, zfs_arc_free_target);
return (1);
}

 Alternatively, I think that the same effect can be achieved by setting
 sysctl
 vfs.zfs.arc_free_target to the same value as vm.stats.vm.v_free_min.
 
 Thats correct that would achieve the same thing.
 
 It's interesting to me whether you would still see the better
 performance or if
 that improvement would be undone.
 
 Indeed that would be interesting, but we might find that its quite
 memory size
 dependent given the scaling so confirming HW details would be nice too.
 
 I'd also be interested to know who wins the free race between the VM and
 ARC
 when using that value.
 
 For those following this thread but not the review, I've added some
 additional
 information there which you might be interested in:
 https://reviews.freebsd.org/D702
 
Regards
Steve

Just an update: I'm in the middle of testing this. I have to finish a
large bulk build to observe the behavior one way or another.

I have 32G of physical memory and 2x16G dedicated swap SSDs (L2ARC
wasn't very useful, but I should probably retest this) on this machine.
My ARC is usually at 14G with ~5G of MFU full of things I benefit from
keeping there (port trees, base jails). Builds themselves happen in
tmpfs and I usually have around 1.5G - 4G Free memory (unless building
something like pypy).

- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

2014-09-03 Thread Nikolai Lifanov 
On 09/03/14 04:09, Steven Hartland wrote:
 I'm looking to MFC this change so wanted to check if
 anyone had an final feedback / objections?
 
 I know we currently have Alan's feedback on changing
 the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
 which sounds sensible but waiting Peter to comment on.
 
Regards
Steve

I have no technical input, but this change improves ARC usefulness for
me quite a bit. I would like to see the improvement in 10-STABLE.

- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

2014-09-03 Thread Nikolai Lifanov 
On 09/03/14 15:22, John Baldwin wrote:
 On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
 On 09/03/14 04:09, Steven Hartland wrote:
 I'm looking to MFC this change so wanted to check if
 anyone had an final feedback / objections?

 I know we currently have Alan's feedback on changing
 the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
 which sounds sensible but waiting Peter to comment on.

Regards
Steve

 I have no technical input, but this change improves ARC usefulness for
 me quite a bit. I would like to see the improvement in 10-STABLE.
 
 Can you verify that the current 10-STABLE (as of today) with all the various 
 pagedaemon fixes still has ARC issues for your workload?
 

It doesn't have any issues, but I noticed the improvement on CURRENT. I
observed that just after this change, my package builder is much more
likely to retain MFU and not evict useful things from there (the port
tree) after large builds.
However, I run a lot more 10.0-RELEASE than CURRENT and I would like to
see this improvement release-bound.

I would be happy to test this on 10-STABLE if you think that this is
relevant.

- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

2014-05-23 Thread Nikolai Lifanov 
 -- sometimes -- run i386 binaries, for example. amd64 may or
may not be able to run i386, depending on kernel options.



You're assuming that you would only use a chroot to RUN things. This is
also useful for building images. Install a world into a chroot, run
pkg -c install whatever and it picks the right ABI. Just an example.


In any case, I wouldn't really characterize this situation as common
in any sense -- and I don't even see why it applies to this
discussion. Whatever logic calculates your own private version of
architecture strings can calculate the correct ones. Allowing it to
ignore the architecture optionally, just like you how you already have
to add flags to install in a chroot, would also work. Lots of things
like that. This issue is basically wholly unrelated to whether you use
normal architecture strings or not.

I'm perfectly happy to write 100% of the code to enable pkg to use the
same architecture strings that the rest of the operating system uses.
Having private ones is just a recipe for confusion. From this
discussion, there don't seem to be any actually existing reasons why
MACHINE_ARCH doesn't work for this.


pkg is *not* FreeBSD-specific. Is MACHINE_ARCH portable?



I don't think it matters whether MACHINE_ARCH is portable. FreeBSD amd64 
binaries are not going to run on Linux x86_64, for example. Setting pkg 
ABI to something like freebsd:arm:armv6hf or freebsd:amd64:amd64 is 
specific enough, and could allow installation if the last triplet is in 
kern.supported_archs. Then you can have linux:fruit:banana packages that 
will correctly not install on freebsd:amd64:amd64. The current mapping 
is not intuitive.


- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r264027 - in head: release share/man/man7

2014-04-02 Thread Nikolai Lifanov 
On 04/02/14 11:51, Glen Barber wrote:
 On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote:
 On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote:
 Author: gjb
 Date: Tue Apr  1 22:41:26 2014
 New Revision: 264027
 URL: http://svnweb.freebsd.org/changeset/base/264027

 Log:
   Add a new release build variable, WITH_COMPRESSED_IMAGES.
   
   When set to a non-empty value, the installation medium is
   compressed with gzip(1) as part of the 'install' target in
   the release/ directory.
   
   With gzip(1) compression, downloadable image are reduced in
   size quite significantly.  Build test against head@263927
   shows the following:
   
bootonly.iso:64% smaller
disc1.iso:   44% smaller
memstick.img:47% smaller
mini-memstick.img:   65% smaller
dvd1.iso:untested
   
   This option is off by default, I would eventually like to
   turn it on by default, and remove the '-k' flag to gzip(1)
   so only compressed images are published on FTP.

 I'd recommend testing xz compression as well.  With UFS images of a full
 world the savings vs gzip are significant (more than 30% IIRC, but it's
 need more than a year since I checked so I'm a bit unsure of the exact
 numbers).

 
 delphij also brought this up.
 
 I have concerns with xz(1), since there was mention in IRC that Windows
 users may have problems decompressing xz-compressed images.  So, gzip(1)
 is used because it seems to be the more commonly-supported archive
 mechanisms.
 
 The benefit of xz(1) over gzip(1) was only 50M-ish.
 
   -rw-r--r--  1 root  wheel   601M Mar 28 20:18 disc1.iso
   -rw-r--r--  1 root  wheel   381M Mar 28 20:18 disc1.iso.bz2
   -rw-r--r--  1 root  wheel   392M Mar 28 20:18 disc1.iso.gz
   -rw-r--r--  1 root  wheel   348M Mar 28 20:18 disc1.iso.xz
 
 Glen
 

How about 7zip (Windows program, not file format)? What would a Windows
user use that can decompress gzip and not xz? It was a problem around
~2007, but xz support is no longer rare or exotic.

- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r264027 - in head: release share/man/man7

2014-04-02 Thread Nikolai Lifanov 
On 04/02/14 12:06, Glen Barber wrote:
 On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote:
 On 04/02/14 11:51, Glen Barber wrote:
 On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote:
 On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote:
 Author: gjb
 Date: Tue Apr  1 22:41:26 2014
 New Revision: 264027
 URL: http://svnweb.freebsd.org/changeset/base/264027

 Log:
   Add a new release build variable, WITH_COMPRESSED_IMAGES.
   
   When set to a non-empty value, the installation medium is
   compressed with gzip(1) as part of the 'install' target in
   the release/ directory.
   
   With gzip(1) compression, downloadable image are reduced in
   size quite significantly.  Build test against head@263927
   shows the following:
   
bootonly.iso:  64% smaller
disc1.iso: 44% smaller
memstick.img:  47% smaller
mini-memstick.img: 65% smaller
dvd1.iso:  untested
   
   This option is off by default, I would eventually like to
   turn it on by default, and remove the '-k' flag to gzip(1)
   so only compressed images are published on FTP.

 I'd recommend testing xz compression as well.  With UFS images of a full
 world the savings vs gzip are significant (more than 30% IIRC, but it's
 need more than a year since I checked so I'm a bit unsure of the exact
 numbers).


 delphij also brought this up.

 I have concerns with xz(1), since there was mention in IRC that Windows
 users may have problems decompressing xz-compressed images.  So, gzip(1)
 is used because it seems to be the more commonly-supported archive
 mechanisms.

 The benefit of xz(1) over gzip(1) was only 50M-ish.

   -rw-r--r--  1 root  wheel   601M Mar 28 20:18 disc1.iso
   -rw-r--r--  1 root  wheel   381M Mar 28 20:18 disc1.iso.bz2
   -rw-r--r--  1 root  wheel   392M Mar 28 20:18 disc1.iso.gz
   -rw-r--r--  1 root  wheel   348M Mar 28 20:18 disc1.iso.xz

 Glen


 How about 7zip (Windows program, not file format)? What would a Windows
 user use that can decompress gzip and not xz? It was a problem around
 ~2007, but xz support is no longer rare or exotic.

 
 I don't know, to be honest.  I have no Windows machines to test, so
 I can only go by what I am told.
 
 Glen
 

I just verified it with 7zip for Windows version 9.22. It extracts
.tar.xz archives and decompresses .xz images.

- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r264027 - in head: release share/man/man7

2014-04-02 Thread Nikolai Lifanov 
On 04/02/14 12:33, Glen Barber wrote:
 On Wed, Apr 02, 2014 at 12:23:46PM -0400, Nikolai Lifanov wrote:
 On 04/02/14 12:06, Glen Barber wrote:
 On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote:
 On 04/02/14 11:51, Glen Barber wrote:
 On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote:
 On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote:
 Author: gjb
 Date: Tue Apr  1 22:41:26 2014
 New Revision: 264027
 URL: http://svnweb.freebsd.org/changeset/base/264027

 Log:
   Add a new release build variable, WITH_COMPRESSED_IMAGES.
   
   When set to a non-empty value, the installation medium is
   compressed with gzip(1) as part of the 'install' target in
   the release/ directory.
   
   With gzip(1) compression, downloadable image are reduced in
   size quite significantly.  Build test against head@263927
   shows the following:
   
bootonly.iso:64% smaller
disc1.iso:   44% smaller
memstick.img:47% smaller
mini-memstick.img:   65% smaller
dvd1.iso:untested
   
   This option is off by default, I would eventually like to
   turn it on by default, and remove the '-k' flag to gzip(1)
   so only compressed images are published on FTP.

 I'd recommend testing xz compression as well.  With UFS images of a full
 world the savings vs gzip are significant (more than 30% IIRC, but it's
 need more than a year since I checked so I'm a bit unsure of the exact
 numbers).


 delphij also brought this up.

 I have concerns with xz(1), since there was mention in IRC that Windows
 users may have problems decompressing xz-compressed images.  So, gzip(1)
 is used because it seems to be the more commonly-supported archive
 mechanisms.

 The benefit of xz(1) over gzip(1) was only 50M-ish.

   -rw-r--r--  1 root  wheel   601M Mar 28 20:18 disc1.iso
   -rw-r--r--  1 root  wheel   381M Mar 28 20:18 disc1.iso.bz2
   -rw-r--r--  1 root  wheel   392M Mar 28 20:18 disc1.iso.gz
   -rw-r--r--  1 root  wheel   348M Mar 28 20:18 disc1.iso.xz

 Glen


 How about 7zip (Windows program, not file format)? What would a Windows
 user use that can decompress gzip and not xz? It was a problem around
 ~2007, but xz support is no longer rare or exotic.


 I don't know, to be honest.  I have no Windows machines to test, so
 I can only go by what I am told.

 Glen


 I just verified it with 7zip for Windows version 9.22. It extracts
 .tar.xz archives and decompresses .xz images.

 
 Great, thank you for confirming.
 
 So, the question I have now is, considering the time it takes to
 compress the image with xz(1) compared to gzip(1), is that worth saving
 the 50MB space?
 
 I do not object to using xz(1), but the compression time difference was
 quite significant.  (I do not have numbers off-hand, but can run the
 compression again.)
 
 Glen
 

Compression is much more expensive. There are different levels too, so
xz -9e my16Gfile.img on a 4 core i7 can take up to 8 hours. Other levels
are cheaper. De-compression (for the end user) is as cheap or cheaper
than gzip. Depending on the chosen compression level, the minimum amount
of RAM required for decompression can also grow. The xz(1) explains
these properties.

- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r258672 - in head: . share/mk

2013-11-27 Thread Nikolai Lifanov 
On 11/26/13 23:54, Peter Wemm wrote:
 Author: peter
 Date: Wed Nov 27 04:54:23 2013
 New Revision: 258672
 URL: http://svnweb.freebsd.org/changeset/base/258672
 
 Log:
   At great personal risk, change the default for LIB32 from yes to no.  As
   mentioned in UPDATING, you can even do it as an as-needed operation after
   doing a buildworld/installworld.  You can set WITH_LIB32=yes in make.conf
   or src.conf.
 
 Modified:
   head/UPDATING
   head/share/mk/bsd.own.mk
 

If you decide to keep this change, can you add LIB32 stuff to optional
obsoletes? Otherwise people will be left with rotting outdated lib32
directories.

Thanks!

- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r254025 - in head/sys: amd64/amd64 arm/arm arm/at91 arm/mv/armadaxp arm/s3c2xx0 arm/xscale/i80321 arm/xscale/i8134x arm/xscale/ixp425 cddl/compat/opensolaris/kern cddl/compat/opensolar

2013-08-07 Thread Nikolai Lifanov 

On 08/07/13 02:21, Jeff Roberson wrote:

Author: jeff
Date: Wed Aug  7 06:21:20 2013
New Revision: 254025
URL: http://svnweb.freebsd.org/changeset/base/254025

Log:
   Replace kernel virtual address space allocation with vmem.  This provides
   transparent layering and better fragmentation.

- Normalize functions that allocate memory to use kmem_*
- Those that allocate address space are named kva_*
- Those that operate on maps are named kmap_*
- Implement recursive allocation handling for kmem_arena in vmem.

   Reviewed by: alc
   Tested by:   pho
   Sponsored by:EMC / Isilon Storage Division

Modified:
   head/sys/amd64/amd64/mp_machdep.c
   head/sys/amd64/amd64/pmap.c
   head/sys/amd64/amd64/sys_machdep.c
   head/sys/amd64/amd64/vm_machdep.c
   head/sys/arm/arm/bus_space_generic.c
   head/sys/arm/arm/busdma_machdep-v6.c
   head/sys/arm/arm/busdma_machdep.c
   head/sys/arm/arm/mp_machdep.c
   head/sys/arm/arm/pmap-v6.c
   head/sys/arm/arm/pmap.c
   head/sys/arm/arm/vm_machdep.c
   head/sys/arm/at91/at91.c
   head/sys/arm/mv/armadaxp/armadaxp_mp.c
   head/sys/arm/s3c2xx0/s3c2xx0_space.c
   head/sys/arm/xscale/i80321/i80321_space.c
   head/sys/arm/xscale/i8134x/i81342_space.c
   head/sys/arm/xscale/ixp425/ixp425_pci_space.c
   head/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c
   head/sys/cddl/compat/opensolaris/sys/kmem.h
   head/sys/compat/linux/linux_misc.c
   head/sys/compat/ndis/subr_ntoskrnl.c
   head/sys/dev/bktr/bktr_core.c
   head/sys/dev/drm/drm_scatter.c
   head/sys/dev/drm2/drm_scatter.c
   head/sys/dev/drm2/i915/intel_ringbuffer.c
   head/sys/dev/drm2/ttm/ttm_bo_util.c
   head/sys/dev/xen/blkback/blkback.c
   head/sys/dev/xen/netback/netback.c
   head/sys/dev/xen/xenpci/xenpci.c
   head/sys/i386/i386/machdep.c
   head/sys/i386/i386/mp_machdep.c
   head/sys/i386/i386/pmap.c
   head/sys/i386/i386/sys_machdep.c
   head/sys/i386/i386/vm_machdep.c
   head/sys/i386/ibcs2/imgact_coff.c
   head/sys/i386/pci/pci_cfgreg.c
   head/sys/i386/xen/mp_machdep.c
   head/sys/i386/xen/pmap.c
   head/sys/ia64/ia64/mp_machdep.c
   head/sys/kern/imgact_gzip.c
   head/sys/kern/init_main.c
   head/sys/kern/kern_exec.c
   head/sys/kern/kern_malloc.c
   head/sys/kern/kern_mbuf.c
   head/sys/kern/kern_sharedpage.c
   head/sys/kern/subr_busdma_bufalloc.c
   head/sys/kern/subr_vmem.c
   head/sys/kern/vfs_bio.c
   head/sys/mips/mips/mp_machdep.c
   head/sys/mips/mips/pmap.c
   head/sys/mips/mips/vm_machdep.c
   head/sys/mips/sibyte/sb_zbpci.c
   head/sys/ofed/include/linux/dma-mapping.h
   head/sys/ofed/include/linux/gfp.h
   head/sys/ofed/include/linux/linux_compat.c
   head/sys/pc98/pc98/machdep.c
   head/sys/powerpc/aim/mmu_oea.c
   head/sys/powerpc/aim/mmu_oea64.c
   head/sys/powerpc/aim/vm_machdep.c
   head/sys/powerpc/booke/pmap.c
   head/sys/powerpc/booke/vm_machdep.c
   head/sys/powerpc/powerpc/busdma_machdep.c
   head/sys/powerpc/powerpc/mp_machdep.c
   head/sys/sparc64/sparc64/bus_machdep.c
   head/sys/sparc64/sparc64/mem.c
   head/sys/sparc64/sparc64/mp_machdep.c
   head/sys/sparc64/sparc64/pmap.c
   head/sys/sparc64/sparc64/vm_machdep.c
   head/sys/vm/memguard.c
   head/sys/vm/memguard.h
   head/sys/vm/pmap.h
   head/sys/vm/uma_core.c
   head/sys/vm/vm_extern.h
   head/sys/vm/vm_glue.c
   head/sys/vm/vm_init.c
   head/sys/vm/vm_kern.c
   head/sys/vm/vm_kern.h
   head/sys/vm/vm_map.c
   head/sys/vm/vm_map.h
   head/sys/vm/vm_object.c
   head/sys/x86/x86/busdma_machdep.c
   head/sys/xen/gnttab.c

Modified: head/sys/amd64/amd64/mp_machdep.c
==
--- head/sys/amd64/amd64/mp_machdep.c   Wed Aug  7 06:05:57 2013
(r254024)
+++ head/sys/amd64/amd64/mp_machdep.c   Wed Aug  7 06:21:20 2013
(r254025)
@@ -938,10 +938,14 @@ start_all_aps(void)
apic_id = cpu_apic_ids[cpu];

/* allocate and set up an idle stack data page */
-   bootstacks[cpu] = (void *)kmem_alloc(kernel_map, KSTACK_PAGES * 
PAGE_SIZE);
-   doublefault_stack = (char *)kmem_alloc(kernel_map, PAGE_SIZE);
-   nmi_stack = (char *)kmem_alloc(kernel_map, PAGE_SIZE);
-   dpcpu = (void *)kmem_alloc(kernel_map, DPCPU_SIZE);
+   bootstacks[cpu] = (void *)kmem_malloc(kernel_arena,
+   KSTACK_PAGES * PAGE_SIZE, M_WAITOK | M_ZERO);
+   doublefault_stack = (char *)kmem_malloc(kernel_arena,
+   PAGE_SIZE, M_WAITOK | M_ZERO);
+   nmi_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE,
+   M_WAITOK | M_ZERO);
+   dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE,
+   M_WAITOK | M_ZERO);

bootSTK = (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE - 
8;
bootAP = cpu;

Modified: head/sys/amd64/amd64/pmap.c
==
--- head/sys/amd64/amd64/pmap.c Wed Aug  7

Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba

2013-06-18 Thread Nikolai Lifanov 

On 06/18/13 12:48, Andre Oppermann wrote:

On 18.06.2013 18:40, Tijl Coosemans wrote:

On 2013-06-18 04:53, Peter Wemm wrote:

Author: peter
Date: Tue Jun 18 02:53:45 2013
New Revision: 251886
URL: http://svnweb.freebsd.org/changeset/base/251886

Log:
   Introduce svnlite so that we can check out our source code again.

   This is actually a fully functional build except:
   * All internal shared libraries are static linked to make sure there
 is no interference with ports (and to reduce build time).
   * It does not have the python/perl/etc plugin or API support.
   * By default, it installs as svnlite rather than svn.
   * If WITH_SVN added in make.conf, you get svn.
   * If WITHOUT_SVNLITE is in make.conf, this is completely disabled.

   To be absolutely clear, this is not intended for any use other than
   checking out freebsd source and committing, like we once did with
cvs.

   It should be usable for small scale local repositories that don't
   need the python/perl plugin architecture.


This ties the repo to the oldest supported release, meaning that years
from now we won't be able to use some new subversion feature because
an old FreeBSD release doesn't support it.


AFAIK there is a checkout-only SVN client available, as in cvsup, but I
don't
remember the name.


I don't find it unreasonable to ask developers to install the port.
And for users it seems all they need is something like portsnap for base.
Portsnap already distributes ports svn so it shouldn't be too hard to
adapt it for base. And the extra layer it adds is very convenient. Apart
from a bigger than usual update maybe, portsnap users never even noticed
it was switched from cvs to svn at some point.


Installing SVN from ports is very painful because of the huge dependency
chain it carries, with the largest being Python and Perl IIRC.



It's net/svnup and is a great replacement for cvs, in my opinion.
CVS wasn't used for development for a long while anyway, so there is 
nothing subversion is replacing that net/svnup wouldn't.


- Nikolai Lifanov

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r246362 - head/games/fortune/datfiles

2013-02-05 Thread Nikolai Lifanov 
) The Los Angeles
 Raiders will never be the team they were when they - called
 Oakland home. - - -- The Limbaugh Letter, Copyright 1992, EFM
 Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: 
 - -(3) Peace does not mean the elimination of nuclear weapons. - -
 -- The Limbaugh Letter, Copyright 1992, EFM Publishing, Inc. -% 
 -Rush Limbaugh's 35 Undeniable Truths of Life: - -(30) The United
 States will again go to war. - -  -- The Limbaugh Letter,
 Copyright 1992, EFM Publishing, Inc. -% -Rush Limbaugh's 35
 Undeniable Truths of Life: - -(31) To more and more American
 intellectuals, a victorious United States - is a sinful United
 States. - -   -- The Limbaugh Letter, Copyright 1992, EFM
 Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: 
 - -(32) The fact that American intellectuals rue a victorious
 United States - is frightening and ominous. - -   -- The
 Limbaugh Letter, Copyright 1992, EFM Publishing, Inc. -% -Rush
 Limbaugh's 35 Undeniable Truths of Life: - -(33) There will always
 be poor people. - -   -- The Limbaugh Letter, Copyright 1992, EFM
 Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: 
 - -(34) The fact that there will always be poor people is not the
 fault of - the rich. - -  -- The Limbaugh Letter, Copyright
 1992, EFM Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths
 of Life: - -(35) Rather than feel guilty as some do, you should
 thank God for making - you an American. - -   -- The Limbaugh
 Letter, Copyright 1992, EFM Publishing, Inc. -% -Rush Limbaugh's
 35 Undeniable Truths of Life: - -(4) Peace does not mean the
 absence of war. - -   -- The Limbaugh Letter, Copyright 1992, EFM
 Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: 
 - -(5) War is not obsolete. - -   -- The Limbaugh Letter, Copyright
 1992, EFM Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths
 of Life: - -(6) Ours is a world governed by the aggressive use of
 force. - --- The Limbaugh Letter, Copyright 1992, EFM
 Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: 
 - -(7) There is only one way to eliminate nuclear weapons. Use
 them. - - -- The Limbaugh Letter, Copyright 1992, EFM Publishing,
 Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: - -(8) Peace
 cannot be achieved merely by developing an understanding -
 among peoples. - --- The Limbaugh Letter, Copyright 1992, EFM
 Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: 
 - -(9) Americans opposing America is not always sacred nor
 courageous ... -it is sometimes dangerous. - --- The Limbaugh
 Letter, Copyright 1992, EFM Publishing, Inc. -% Said a dainty
 young whore named Ms. Meggs, The men like to spread my two legs, 
 Then slip in between, 
 ___ 
 svn-src-h...@freebsd.org mailing list 
 http://lists.freebsd.org/mailman/listinfo/svn-src-head To
 unsubscribe, send any mail to
 svn-src-head-unsubscr...@freebsd.org
 

Remove political propaganda -- Why?
This is the offensive file.
It's supposed to have potentially offensive political, sexist,
religious, racist, and miscellaneously off content.

The man page is clear about this and comes with a warning.

- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org