headers
Kamal R. Prasad | 1 Dec 2006 06:28
Picon
Favicon

Re: contiguous memory allocation problem

Hello,

 I would like to unsubscribe myself from all freebsd mailing lists. I have
sent an unsubscribe to freebsd-hackers-unsubscribe, but did not get any
response to verify. Since the admin is on the mailing list, I would
appreciate if you can delete my name and/or email me the procedure to
follow.

thanks
-kamal

On 7/3/06, Julian Elischer <julian <at> elischer.org> wrote:
>
> Ian Dowse wrote:
>
> >In message <200607021138.11945.hselasky <at> c2i.net>, Hans Petter Selasky
> writes:
> >
> >
> >>But there is one problem, that has been overlooked, and that is High
> speed
> >>isochronous transfers, which are not supported by the existing USB
> system. I
> >>don't think that the EHCI specification was designed for scatter and
> gather,
> >>when you consider this:
> >>
> >>8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to
> work,
> >>and I am right, one page has to contain two transfers. (see page 43 of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eldar T. Zaitov | 1 Dec 2006 10:34
Picon

jail2 patchset 14

Have tried Jail2 patchset #14 on 6.2-PRERELEASE, everything compiles and
works ok, but resolve.
gethostbyname always returns NULL, but host/dig works ok.
here's an example:

virtual# host mail.ru
mail.ru has address 194.67.57.26
mail.ru mail is handled by 10 mxs.mail.ru.
virtual# ping mail.ru
ping: cannot resolve mail.ru: Host name lookup failure

here is some truss output of 'ping mail.ru':
kqueue()                                         = 4 (0x4)
socket(PF_INET,SOCK_DGRAM,0)                     = 5 (0x5)
connect(5,{ AF_INET ***.62.171.***:53 },16)       ERR#22 'Invalid argument'
close(5)                                         = 0 (0x0)
socket(PF_INET,SOCK_DGRAM,0)                     = 5 (0x5)
connect(5,{ AF_INET ***.62.171.***:53 },16)       ERR#22 'Invalid argument'
close(5)                                         = 0 (0x0)
close(4)                                         = 0 (0x0)

where
***.62.171.***:53 is nameserver;
***  is masked ip nodes;

may be I've forgotten something?
thank you.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Hartland | 1 Dec 2006 11:43
Picon
Favicon

Unable to stop a jail

We've got a jail here which we cant stop with either killall
jexec or jkill all return success but jls still reports
the jail as running.

The machines running several other jails which I cant restart
at this time so I ended up starting the jail again jls
now reports:
jls
   JID  IP Address      Hostname   Path
     9  10.10.0.5     jail6        /usr/local/jails/jail6
     7  10.10.0.5     jail6        /usr/local/jails/jail6
     6  10.10.0.4     jail5        /usr/local/jails/jail5
     5  10.10.0.39    jail4        /usr/local/jails/jail4
     3  10.10.0.6     jail3        /usr/local/jails/jail3
     2  10.10.0.8     jail2        /usr/local/jails/jail2
     1  10.10.0.7     jail1        /usr/local/jails/jail1

Host machine is running FreeBSD-6.1-P10

Any ideas some sort of kernel data corruption?

    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is
addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or
otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster <at> multiplay.co.uk.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Maxim Konovalov | 1 Dec 2006 11:47
Picon

Re: Unable to stop a jail

On Fri, 1 Dec 2006, 10:43-0000, Steven Hartland wrote:

> We've got a jail here which we cant stop with either killall
> jexec or jkill all return success but jls still reports
> the jail as running.
>
> The machines running several other jails which I cant restart
> at this time so I ended up starting the jail again jls
> now reports:
> jls
>   JID  IP Address      Hostname   Path
>     9  10.10.0.5     jail6        /usr/local/jails/jail6
>     7  10.10.0.5     jail6        /usr/local/jails/jail6
>     6  10.10.0.4     jail5        /usr/local/jails/jail5
>     5  10.10.0.39    jail4        /usr/local/jails/jail4
>     3  10.10.0.6     jail3        /usr/local/jails/jail3
>     2  10.10.0.8     jail2        /usr/local/jails/jail2
>     1  10.10.0.7     jail1        /usr/local/jails/jail1
>
> Host machine is running FreeBSD-6.1-P10
>
> Any ideas some sort of kernel data corruption?

Known bug, discussed several times.  IIRC leaked struct ucred.

--

-- 
Maxim Konovalov
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern A. Zeeb | 1 Dec 2006 11:49

Re: Unable to stop a jail

On Fri, 1 Dec 2006, Steven Hartland wrote:

Hi,

> We've got a jail here which we cant stop with either killall
> jexec or jkill all return success but jls still reports
> the jail as running.
>
> The machines running several other jails which I cant restart
> at this time so I ended up starting the jail again jls
> now reports:
> jls
>  JID  IP Address      Hostname   Path
>    9  10.10.0.5     jail6        /usr/local/jails/jail6
>    7  10.10.0.5     jail6        /usr/local/jails/jail6
>    6  10.10.0.4     jail5        /usr/local/jails/jail5
>    5  10.10.0.39    jail4        /usr/local/jails/jail4
>    3  10.10.0.6     jail3        /usr/local/jails/jail3
>    2  10.10.0.8     jail2        /usr/local/jails/jail2
>    1  10.10.0.7     jail1        /usr/local/jails/jail1
>
> Host machine is running FreeBSD-6.1-P10
>
> Any ideas some sort of kernel data corruption?

no the jails should really be gone (you should not find any
sockets or processes for them after some seconds) - at least
it should be that way...

See
(Continue reading)

Permalink | Reply | 3 comments |
headers
Robert Watson | 1 Dec 2006 12:15
Picon
Favicon

Re: Unable to stop a jail


On Fri, 1 Dec 2006, Bjoern A. Zeeb wrote:

> On Fri, 1 Dec 2006, Steven Hartland wrote:
>
>> We've got a jail here which we cant stop with either killall jexec or jkill 
>> all return success but jls still reports the jail as running.
>> 
>> The machines running several other jails which I cant restart at this time 
>> so I ended up starting the jail again jls now reports: jls
>>  JID  IP Address      Hostname   Path
>>    9  10.10.0.5     jail6        /usr/local/jails/jail6
>>    7  10.10.0.5     jail6        /usr/local/jails/jail6
>>    6  10.10.0.4     jail5        /usr/local/jails/jail5
>>    5  10.10.0.39    jail4        /usr/local/jails/jail4
>>    3  10.10.0.6     jail3        /usr/local/jails/jail3
>>    2  10.10.0.8     jail2        /usr/local/jails/jail2
>>    1  10.10.0.7     jail1        /usr/local/jails/jail1
>> 
>> Host machine is running FreeBSD-6.1-P10
>> 
>> Any ideas some sort of kernel data corruption?
>
> no the jails should really be gone (you should not find any sockets or 
> processes for them after some seconds) - at least it should be that way...
>
> See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528

Not all cases of straggling jails are leaks -- does netstat -n show that all 
the TIME_WAIT TCP connections in the jail have been GC'd?  Because security
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steven Hartland | 1 Dec 2006 12:41
Picon
Favicon

Re: Unable to stop a jail

Robert Watson wrote:
> Not all cases of straggling jails are leaks -- does netstat -n show
> that all the TIME_WAIT TCP connections in the jail have been GC'd? 
> Because security state may be used in the network stack for TCP
> packet transmission/reception, the ucred remains referenced until the
> last socket/pcb associated with it are free'd.  I've been wondering
> if we should add a jail process counter, and hide jails in jls if the
> counter is zero (with a -a argument or such to show them). One idea
> I've been kicking around is adding a zombie state for jails, in which
> some straggling references exist, but (a) there are no processes in
> the jail, and (b) no new processes are allowed to enter the jail. 
> The significance of (b) is that we could vrele() the vnode reference
> hung off the jail; there's been at least one report that this vnode
> reference causes issues, as the file system it's from can't be
> unmounted until the last jail reference evaporates.

This appears to not be the case here as there where no references
to the address in netstat and no processes remaining. So it does
seem there is some sort of leak still remaining there someone
where.

At one point I did have two "zombie" jails ( of the same jail )
but the second one was due to a socket reference which then
just disappeared a minute or so later.

> In essence, this would move to having two reference counts on the
> prison: a "strong" reference that has to do with having process
> members, and a "weak" reference that has to do with ucreds pointing
> at the prison.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Watson | 1 Dec 2006 13:43
Picon
Favicon

Re: Unable to stop a jail


On Fri, 1 Dec 2006, Steven Hartland wrote:

>> In essence, this would move to having two reference counts on the prison: a 
>> "strong" reference that has to do with having process members, and a "weak" 
>> reference that has to do with ucreds pointing at the prison.
>
> The proposal sounds like a good idea but I'm sure there's an argument that 
> would say thats just hiding the real underlieing issue?

Well, there are two things going on here:

(1) Jails that last a long time due to being referenced by data structures
     that last a long time.  I.e., time-wait TCP connections.

(2) Leaks in credentials or jails resulting in jails that never go away.

What I describe is intended to address the former issue, which is one that 
exists for a reason.  The latter issues are clearly bugs and just need to be 
fixed.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oleg Dambaev | 1 Dec 2006 11:00
Picon

Re: jail2 patchset 14

Eldar T. Zaitov wrote:
> Have tried Jail2 patchset #14 on 6.2-PRERELEASE, everything compiles and
> works ok, but resolve.
> gethostbyname always returns NULL, but host/dig works ok.
> here's an example:
>
> virtual# host mail.ru
> mail.ru has address 194.67.57.26
> mail.ru mail is handled by 10 mxs.mail.ru.
> virtual# ping mail.ru
> ping: cannot resolve mail.ru: Host name lookup failure
>
> here is some truss output of 'ping mail.ru':
> kqueue()                                         = 4 (0x4)
> socket(PF_INET,SOCK_DGRAM,0)                     = 5 (0x5)
> connect(5,{ AF_INET ***.62.171.***:53 },16)       ERR#22 'Invalid argument'
> close(5)                                         = 0 (0x0)
> socket(PF_INET,SOCK_DGRAM,0)                     = 5 (0x5)
> connect(5,{ AF_INET ***.62.171.***:53 },16)       ERR#22 'Invalid argument'
> close(5)                                         = 0 (0x0)
> close(4)                                         = 0 (0x0)
>
> where
> ***.62.171.***:53 is nameserver;
> ***  is masked ip nodes;
>
> may be I've forgotten something?
> thank you.
Hope this would help you:
sysctl security.jail.allow_raw_sockets=1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daichi GOTO | 1 Dec 2006 14:38
Picon
Favicon

[ANN] unionfs patchset-17 release, lock mechanism changed for robust working

Hi Guys!

It is my pleasure and honor to announce the availability of
the unionfs patchset-17. p17 have some significant improvements
around the lock mechanism for robust and stable working.

Patchset-17:
   For 7-current
     http://people.freebsd.org/~daichi/unionfs/unionfs-p17.diff

   For 6.x
     sorry, it is for current only.

   Changes in unionfs-p17.diff
     - Fs takes illegal access without lock of lower layer
       vnode if the both upper/lower layers have both vnode.
       To fix this problem, we change the lock mechanism to
       get locks for both upper/lower layer always.
     - Kernel gets a dead-lock easily within above
       upper/lower-layer-always-lock-mechanism. To avoide
       above dead-lock, we changed vfs_lookup.c. By that change,
       it always locks vnodes parent first and children second.
       You could see the same lock-order-control implementation
       around cache_lookup.
     - It takes the both open/close operations per kernel thread.
     - It takes readdir-treat-status-management per kernel thread.
     - It reopens vnode if needed when coping to upper layer on
       advlock.
     - mount_unionfs(8) changes option style fitting for fstab(5)
       style. (by rodrigc)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane