On 26.05.2014 17:31, Vladimir Sharun wrote:
> Hello FreeBSD community,
>
> Recently plays with securelevel and what I discover: no chance for
> data to survive against remote root, except backups of course. Maybe
> this log can be a proposal for raising securelevel further or include
> securelevel
Hello,
> if you have root privileges you can just write some random bytes in some
> places and this will be enough to break your system. So, restricting
> some gpart's or zpool's actions depending from securelevel looks like
> protection from kids.
Having root under securelevel 3 confirmed disall
On 29 May 2014, at 02:23, Bryan Drewery wrote:
> As for skipping unneeded ports the best I can do is '-a' or "Build it all".
> If a port is only needed for WITH_X11 then an IGNORE should be added to it
> when WITHOUT_X11 is set to prevent wasting time on it.
We can probably do a bit better by lo
On 29.05.2014 12:56, Vladimir Sharun wrote:
> Hello,
>
>> if you have root privileges you can just write some random bytes in some
>> places and this will be enough to break your system. So, restricting
>> some gpart's or zpool's actions depending from securelevel looks like
>> protection from kid
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014 amd64
I'm also loading the Radeon_kms modules
Upon system startup, memory profile is clean. I get locked memory (mem_wire)
usage as:
9% before Radeon*.ko modules loaded
12% when slim is started (loads Radeon*.ko modules)
14
Hello,
> Ok, you are right. But geom_dev restricts access only from user level
> applications. When GEOM object does access directly via GEOM methods
> this protection won't work. And it seems it isn't easy to fix, all
> classes should have own check.
Thank you for better clarification. This is t
Are there any problems with MFC?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/newcons-and-beeping-X-tp5906883p5916170.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org maili
TB --- 2014-05-29 11:00:39 - tinderbox 2.22 running on freebsd-current.sentex.ca
TB --- 2014-05-29 11:00:39 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2014
> On May 29, 2014, at 4:19, David Chisnall wrote:
>
>> On 29 May 2014, at 02:23, Bryan Drewery wrote:
>>
>> As for skipping unneeded ports the best I can do is '-a' or "Build it all".
>> If a port is only needed for WITH_X11 then an IGNORE should be added to it
>> when WITHOUT_X11 is set to pr
On Mon, 12 May 2014 17:10:54 +0200
Claude Buisson wrote:
> On 05/12/2014 16:14, Aleksandr Rybalko wrote:
> > On Mon, 12 May 2014 15:35:48 +0200
> > Claude Buisson wrote:
> >
> >> On 03/11/2014 15:27, Aleksandr Rybalko wrote:
> >>> Hello hackers!
> >>>
> >>> Here is link to the patch[1] for vidco
On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
> uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014 amd64
> I'm also loading the Radeon_kms modules
>
> Upon system startup, memory profile is clean. I get locked memory (mem_wire)
> usage as:
> 9%before Radeon*.ko modules
On Thu, 29 May 2014 09:08:10 -0400
John Baldwin wrote:
> On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
> > uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
> > amd64 I'm also loading the Radeon_kms modules
> >
> >
> > I don't know if the lsof dump in single user mode
On 2014-05-29 08:42, Bryan Drewery wrote:
>
>> On May 29, 2014, at 4:19, David Chisnall wrote:
>>
>>> On 29 May 2014, at 02:23, Bryan Drewery wrote:
>>>
>>> As for skipping unneeded ports the best I can do is '-a' or "Build it all".
>>> If a port is only needed for WITH_X11 then an IGNORE should
On 2014-05-29 09:57, Alexander Kabaev wrote:
> On Thu, 29 May 2014 09:08:10 -0400
> John Baldwin wrote:
>
>> On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
>>> uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
>>> amd64 I'm also loading the Radeon_kms modules
>>>
>
>>>
>>
>> Why do you think libc.so.7 has anything to do with this?
Well, because there are two instances of it running in the lsof dump, with
several possible "child process" candidates. Why would they be hanging
around when practically everything has been killed?
Radeon*.ko modules are a very strong pos
On 05/29/2014 15:17, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 17:10:54 +0200
Claude Buisson wrote:
On 05/12/2014 16:14, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 15:35:48 +0200
Claude Buisson wrote:
On 03/11/2014 15:27, Aleksandr Rybalko wrote:
Hello hackers!
Here is link to the p
On Thursday, May 29, 2014 9:57:22 am Alexander Kabaev wrote:
> On Thu, 29 May 2014 09:08:10 -0400
> John Baldwin wrote:
>
> > On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
> > > uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
> > > amd64 I'm also loading the Radeon_kms
On Thu, May 29, 2014 at 7:56 AM, Claude Buisson wrote:
> On 05/29/2014 15:17, Aleksandr Rybalko wrote:
>
>> On Mon, 12 May 2014 17:10:54 +0200
>> Claude Buisson wrote:
>>
>> On 05/12/2014 16:14, Aleksandr Rybalko wrote:
>>>
On Mon, 12 May 2014 15:35:48 +0200
Claude Buisson wrote:
>>>
On 2014-05-29 12:04, John Baldwin wrote:
> On Thursday, May 29, 2014 9:57:22 am Alexander Kabaev wrote:
>> On Thu, 29 May 2014 09:08:10 -0400
>> John Baldwin wrote:
>>
>>> On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
Hey all,
http://www.brendangregg.com/Perf/linuxperftools.png is a neat diagram.
Who wants to make one for FreeBSD? It'll even make its way to our
website & documentation :)
--
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.fre
On 28 May 2014 10:58, John Baldwin wrote:
> On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
>> On 28 May 2014 06:56, John Baldwin wrote:
>>
>>
>> > Userland cpusets only default to 128 (CPU_MAXSIZE in ).
>> > Changing MAXCPU to even 128 is unfortunately a potential KBI change since
>>
On Thursday, May 29, 2014 10:42:18 am Beeblebrox wrote:
> >> Why do you think libc.so.7 has anything to do with this?
>
> Well, because there are two instances of it running in the lsof dump, with
> several possible "child process" candidates. Why would they be hanging
> around when practically ev
On Thursday, May 29, 2014 12:53:54 pm Adrian Chadd wrote:
> On 28 May 2014 10:58, John Baldwin wrote:
> > On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
> >> On 28 May 2014 06:56, John Baldwin wrote:
> >>
> >>
> >> > Userland cpusets only default to 128 (CPU_MAXSIZE in ).
> >> > Changi
On 29 May 2014 10:18, John Baldwin wrote:
>> > It costs wired memory to increase it for the kernel. The userland set size
>> > can be increased rather arbitrarily, so we don't need to make it but so
>> > large
>> > as it is easy to bump later (even with a branch).
>>
>> Well, what about making
On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> On 29 May 2014 10:18, John Baldwin wrote:
>
> >> > It costs wired memory to increase it for the kernel. The userland set
> >> > size
> >> > can be increased rather arbitrarily, so we don't need to make it but so
> >> > large
> >> > as
On Thu, May 29, 2014 at 02:44:19PM -0400, John Baldwin wrote:
> On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> > On 29 May 2014 10:18, John Baldwin wrote:
> >
> > >> > It costs wired memory to increase it for the kernel. The userland set
> > >> > size
> > >> > can be increased rathe
On 29 May 2014 11:44, John Baldwin wrote:
> On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
>> On 29 May 2014 10:18, John Baldwin wrote:
>>
>> >> > It costs wired memory to increase it for the kernel. The userland set
>> >> > size
>> >> > can be increased rather arbitrarily, so we don'
On Thu, 29 May 2014 09:11:04 -0700
Kevin Oberman wrote:
> On Thu, May 29, 2014 at 7:56 AM, Claude Buisson
> wrote:
>
> > On 05/29/2014 15:17, Aleksandr Rybalko wrote:
> >
> >> On Mon, 12 May 2014 17:10:54 +0200
> >> Claude Buisson wrote:
> >>
> >> On 05/12/2014 16:14, Aleksandr Rybalko wrote:
On Thursday, May 29, 2014 4:05:49 pm Adrian Chadd wrote:
> On 29 May 2014 11:44, John Baldwin wrote:
> > On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> >> On 29 May 2014 10:18, John Baldwin wrote:
> >>
> >> >> > It costs wired memory to increase it for the kernel. The userland
> >>
On Thursday, May 29, 2014 3:27:57 pm Konstantin Belousov wrote:
> On Thu, May 29, 2014 at 02:44:19PM -0400, John Baldwin wrote:
> > On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> > > On 29 May 2014 10:18, John Baldwin wrote:
> > >
> > > >> > It costs wired memory to increase it for th
On 29 May 2014 13:18, John Baldwin wrote:
>> anyway. Besides all of this - I'm thinking of just introducing:
>>
>> typedef uint32_t cpuid_t;
>>
>> .. then once we've converted all the users, we can make NOCPU
>> something other than 255 (which is the other limiting factor here..)
>>
>> Any object
On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote:
> On 29 May 2014 13:18, John Baldwin wrote:
>
> >> anyway. Besides all of this - I'm thinking of just introducing:
> >>
> >> typedef uint32_t cpuid_t;
> >>
> >> .. then once we've converted all the users, we can make NOCPU
> >> something ot
On 29 May 2014 14:29, John Baldwin wrote:
> On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote:
>> On 29 May 2014 13:18, John Baldwin wrote:
>>
>> >> anyway. Besides all of this - I'm thinking of just introducing:
>> >>
>> >> typedef uint32_t cpuid_t;
>> >>
>> >> .. then once we've converted
On 29.05.2014 06:57, Fred Pedrisa wrote:
> Hello,
>
> There are 4 threads, and a total of 32 FDs. What do you think ?
>
> -Mensagem original-
> De: owner-freebsd-curr...@freebsd.org
> [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Adrian Chadd
> Enviada em: quinta-feira, 29 de maio
On Thu, May 29, 2014 at 4:20 PM, Allan Jude wrote:
> On 2014-05-29 08:42, Bryan Drewery wrote:
> >
> >> On May 29, 2014, at 4:19, David Chisnall wrote:
> >>
> >>> On 29 May 2014, at 02:23, Bryan Drewery wrote:
> >>>
> >>> As for skipping unneeded ports the best I can do is '-a' or "Build it
> a
Ok.
Thanks for the enlightenment :)
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp
Enviada em: quinta-feira, 29 de maio de 2014 18:55
Para: 'freebsd-current'
Assunto: Re: RES: KQueue vs Select (NetMap)
On 29.05
I'm replying late, but last night I almost had a complete meltdown of the
system.
I did a partial "pkg upgrade" for the packages that managed to get built by
poudriere, then all hell broke loose. Screen lock-ups, random reboots, and
several hard reboots later I decided to do a fresh buildworld/bui
37 matches
Mail list logo
