s an educated guess I would say that vn_alloc_hard() is
> waiting a long time or even forever to allocate new vnodes.
>
> I can provide more information, I just need to know what.
>
>
> Regards,
> Yamagi
>
> --
> Homepage: https://www.yamagi.org
> Github: https://g
wrote:
> Hi Mateusz,
> the sysctl output after about 10 minutes into the problem is attached.
> In case that its stripped by Mailman a copy can be found here:
> https://deponie.yamagi.org/temp/sysctl_vlruwk.txt.xz
>
> Regards,
> Yamagi
>
> On Wed, 17 Mar 2021 15:57:59 +0100
uess I would say that vn_alloc_hard() is
> waiting a long time or even forever to allocate new vnodes.
>
> I can provide more information, I just need to know what.
>
>
> Regards,
> Yamagi
>
> --
> Homepage: https://www.yamagi.org
> Github: https://github.com/yamagi
>
t; > root@jhost002:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>> >
>> > uname -a
>> > FreeBSD jhost002 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 #7
>> > c256260-g247f652e622d: Tue Feb 2 13:07:37 CET 2021
>> > root@jhost002:/usr/obj/usr/src/amd64.amd64/s
On Mon, Jan 02, 2017 at 08:33:29AM -0500, Aryeh Friedman wrote:
> On Mon, Jan 2, 2017 at 7:57 AM, Mateusz Guzik wrote:
>
> > On Mon, Jan 02, 2017 at 07:48:22AM -0500, Aryeh Friedman wrote:
> > > On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik wrote:
> > >
> &g
On Mon, Jan 02, 2017 at 07:48:22AM -0500, Aryeh Friedman wrote:
> On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik wrote:
>
> > On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
> > > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan 1
&g
tions WITNESS # Enable checks to detect deadlocks and
cycles
options WITNESS_SKIPSPIN# Don't run witness on spinlocks for
speed
options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
options DEBUG_VFS_LOCKS
--
Mateusz Guzik
_
ot;private purposes" (i.e.
> > disregarding possible attacks with jailing processes). The real work is
> > making the whole business safe.
>
> I agree.
>
> Is there any project ongoing for this sysvipc issue?
> If any, what is needed to be done?
>
I am unaware of any work being done in the area.
I stated what needs to be done in my first e-mail.
--
Mateusz Guzik
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
to tell
me whether given process has a shared address space. There is only a
vm_refcnt counter in vmspace which is modified on various occasions,
thus is not suitable. Adding a separate counter sucks and adding a "once
set, never cleared flag" sucks as well. Maybe there is a g
ome other thread is forking? This may be
buggy as it is already, but that's roughly the scheme.
It looks like we have some weird miscommunication here, so let me
restate.
I do see great benefit in having jail-aware ipcs.
I do not believe the way to achieve it is to add jail-aware permission
ch
information leaks (no id list
to look at) and conflicts.
Exporting is not a problem either - a dedicated sysctl grabs JID and
dumps its ipcs. It also gets a 'recursive' flag to know whether ipcs
for its own jails should be dumped as well (if different).
--
Mateusz Guzik
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
.0.txt) is here:
> > http://user.lamaiziere.net/patrick/panic_gam_server.txt
>
> With WITNESS and ASSERTION on, I see a warning that looks related :
>
> Jul 14 16:23:29 roxette kernel: WARNING: destroying knlist w/ knotes on it!
>
> and the
like
> >to help finding the source, but have missed the whole new jail evolution...
> >Inside my jails, I don't have a fstab, outside I have them defined and
> >enabled with "mount" - and noticed the non-reverted umounting.
>
> I found the problem - I n
and it held a reference for
/.jail.jailname1's vnode.
jls -v should show the jail.
I don't know if this can happen, but my guess is that not-yet-expired
network connections hold reference to a jail preventing it from being
destroyed. So I would definitely checkout netstat o
On Sun, Jan 13, 2013 at 01:43:03AM +, Ben Morrow wrote:
> Quoth Mateusz Guzik :
> > On Sat, Jan 12, 2013 at 11:29:14PM +, Ben Morrow wrote:
> > > Quoth Derek Kulinski :
> > > >
> > > > I personally really like OpenSuSE command which is: zypp
tely
normal
But even if we use -v, I don't think we can reliably distinguish
"regular" unlinked file mapping from shared library mapping (for
unlinked files we will get - as a name, just like in -f case). I didn't
dig into this though.
Instead I
7.x branch.
> >
>
> The tunable was merged to stable/8 in March 2011 and
> first appeared in 8.3. It was never merged to stable/7.
> IIRC it should be quite easy to adopt those patches to stable/7.
>
stable/7 will be out of support in 3 months.
On Fri, Nov 02, 2012 at 02:59:29PM -0400, Gary Palmer wrote:
> On Fri, Nov 02, 2012 at 07:41:31PM +0100, Mateusz Guzik wrote:
> > On Fri, Nov 02, 2012 at 07:30:04PM +0100, Bas Smeelen wrote:
> > > On 11/02/2012 07:17 PM, Bas Smeelen wrote:
> > > > On 11/02/20
l/partedit/gpart_ops.c
@@ -91,7 +91,7 @@ newfs_command(const char *fstype, char *command, int
use_default)
"Enable softupdates (default)", 1 },
{"SUJ", "Softupdates journaling",
landmine it plants. If they know how
> to turn it on they're much more likely to be aware of the issue.
>
That being said, sure, you may run into another bugs, but if SUJ was
enabled by default I guess it was felt that it works well enough (and in
case of
On Sat, Oct 20, 2012 at 07:10:19AM -0700, David Wolfskill wrote:
> This seems ... fairly weird to me.
>
> Yesterday, I built & booted:
>
> FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #274
> 241726M: Fri Oct 19 05:40:05 PDT 2012
> r...@g1-227.catwhisker.org:/usr/obj/u
freebsd32_exec_copyin_args undefined
> Sep 6 09:14:02 zfs kernel: linker_load_file: Unsupported file type
>
> So how do I get freebsd32_exec_copyin_args defined
>
Most likely:
options COMPAT_FREEBSD32
--
Mateusz Guzik
___
freebs
echo).
>
> I tried vi instead of less, not really wanting to edit the file,
> and vi tried to open a temporary file on /tmp with a strange name.
>
That's expected.
--
Mateusz Guzik
___
freebsd-stable@freebsd.org mailing list
ht
It would be best if you provide:
- version of your system
- your gg.exports config
- exact ggatec command you ran
- backtrace from the panic
--
Mateusz Guzik
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Thu, May 24, 2012 at 06:47:30PM -0600, Jamie Gritton wrote:
> On 05/24/12 16:59, Mateusz Guzik wrote:
> >On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote:
> >>I'll get the patch to jail(8) in - thanks for catching that. But I
> >>wonder about the p
g said, if this is idea sounds
okay, I can try to come up with a patch this weekend.
--
Mateusz Guzik
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Thu, May 24, 2012 at 06:20:15PM -0400, Mike Jakubik wrote:
> On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote:
> > On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote:
> > > On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote:
> > > > On Thu, Ma
On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote:
> On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote:
> > On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote:
> > > Hello,
> > >
> > > Latest 9-STABLE has introduced some changes that
> jails)
>
Try this:
http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch
cd /usr/src && patch -p1 < patch && cd usr.sbin/jail && make && make install
/usr/src/etc/rc.d/jail script can be just copied over.
Note that your /va
lized racct structure, which in turn results in this
panic.
Can you please test this patch:
http://student.agh.edu.pl/~mjguzik/patches/racct-fork.patch
?
I was unable to reproduce panic you describe, so it was tested only by
manually injecting error. Nevertheless I think you should try it. :)
ng, while on FreeBSD
it is 104.
With recent security patch anything bigger than 104 is disallowed, so
support for unix
sockets in linuxolator is broken.
I propose the following patch:
http://student.agh.edu.pl/~mjguzik/linux_sockaddr_un.patch
Thanks,
--
Mateusz Guzik
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
31 matches
Mail list logo
