>#14 0xc01ff64e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 46137344,
> tf_esi = -1071149988, tf_ebp = -999002244, tf_isp = -999002304,
> tf_ebx = 18341888, tf_edx = -1000615936, tf_ecx = -1005747008,
> tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071650796, tf_cs = 8,
:
:> Matthew Dillon wrote:
:> >
:> > We'll get a quick fix committed but the lockmgr stuff needs a real
:> > going-over... having interrupts using the general lockmgr call is
:> > a disaster waiting to happen.
:>
:> Hmmm. After I looked a bit further, it looks like a bug in the
:> sc
On Mon, 15 Mar 1999, Dmitrij Tejblum wrote:
> Matthew Dillon wrote:
> >
> > We'll get a quick fix committed but the lockmgr stuff needs a real
> > going-over... having interrupts using the general lockmgr call is
> > a disaster waiting to happen.
>
> Hmmm. After I looked a bit furthe
Matthew Dillon wrote:
>
> We'll get a quick fix committed but the lockmgr stuff needs a real
> going-over... having interrupts using the general lockmgr call is
> a disaster waiting to happen.
Hmmm. After I looked a bit further, it looks like a bug in the
scheduler (?). Here is the s
On Mon, 15 Mar 1999, Dmitrij Tejblum wrote:
> Matthew Dillon wrote:
> > - error = acquire(lkp, extflags,
> > - LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE);
> > + if (p->p_flag & P_DEADLKTREAT) {
> > + error
:Matthew Dillon wrote:
:> -error = acquire(lkp, extflags,
:> -LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE);
:> +if (p->p_flag & P_DEADLKTREAT) {
:> +error = acquire(
:
:This is broken: p may be NULL, i
Matthew Dillon wrote:
> - error = acquire(lkp, extflags,
> - LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE);
> + if (p->p_flag & P_DEADLKTREAT) {
> + error = acquire(
This is broken: p may be NULL, it i
At 04:35 PM 3/4/99 -0800, Matthew Dillon wrote:
>Well, this was easy to duplicate. I'll try to track it down. It seems
>to occur under -4.x as well as -3.x. Definitely an inode deadlock of
some
>kind.
>
> -Matt
>
>:Try changing the 'find' to
On Fri, 5 Mar 1999, Studded wrote:
> The source is your only guide unfortunately. Several people have
> promised to do a comprehensive list and update the man page, but no one
> has come through yet. If you do the research please share your results.
Okay, now I know... knowing's half the b
m...@seidata.com wrote:
>
> On Thu, 4 Mar 1999, Chris Costello wrote:
>
> >Add /etc/login.conf restrictions if you don't want your users
> > to do that.
>
> Speaking of which... I've always used login.conf to set limits for
> specific user classes... However, it seems like some login.conf
Peter Jeremy wrote:
>
> Another interim solution would be to `fix' GNU grep so it doesn't
> attempt to read() into mmap()'d space. (Having not looked at the
> code, I don't know how difficult this would be).
Pretend the DoS attack does not exist? :-)
I'd hate to make such a grave problem less o
On Thu, 4 Mar 1999, Chris Costello wrote:
>Add /etc/login.conf restrictions if you don't want your users
> to do that.
Speaking of which... I've always used login.conf to set limits for
specific user classes... However, it seems like some login.conf
options just don't work. Is there a plac
> -Original Message-
> From: Peter Jeremy [SMTP:peter.jer...@auss2.alcatel.com.au]
> Sent: Friday, March 05, 1999 4:25 AM
> To: dil...@apollo.backplane.com
> Cc: curr...@freebsd.org
> Subject: Re: Simple DOS against 3.x locks box solid
>
>
> As for
:Hi Matt,
:
:You wrote:
:>We really need to fix the kernel, I think. This sort of deadlock
:>situation has been a problem for too long and it is only going to
:>get worse as more programs use mmap().
:
:I agree. Since you suggest that the kernel fix is going to be a
:while, I was sugg
:Another interim solution would be to `fix' GNU grep so it doesn't
:attempt to read() into mmap()'d space. (Having not looked at the
:code, I don't know how difficult this would be).
:
:As for the general problem, is it sensible to allow a read-only file to
:be mmap'd R/W (with or without MAP_PRIV
Matthew Dillon wrote:
>The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
>the file, but then it does some really weird crap when dealing with
>larger files.
...
>The solution is more difficult. We could hack an exception for PRIVATE
>mmap's... there reall
The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
the file, but then it does some really weird crap when dealing with
larger files.
It's the most idiotic code I've ever seen. The code uses a PRIVATE+RW
mmap() until it gets to odd point in the file, at whic
At 07:22 PM 3/4/99 , Matthew Dillon wrote:
>Well, 10 processes doing a find are not supposed to lockup a machine.
>
>However, there is another potential problem with the script below ... if
>the script is run as root, the find will cross mount points including
>the /proc mount point
Well, this was easy to duplicate. I'll try to track it down. It seems
to occur under -4.x as well as -3.x. Definitely an inode deadlock of some
kind.
-Matt
:Try changing the 'find' to 'find -x'. If this still locks up the machine
:we
Well, 10 processes doing a find are not supposed to lockup a machine.
However, there is another potential problem with the script below ... if
the script is run as root, the find will cross mount points including
the /proc mount point. Now running xargs and random process's memory
On Thu, Mar 4, 1999, Mike Tancsa put this into my mailbox:
>
> Is there any way to stop what is below ?
Yep. Don't do it!
Seriously, though, that puts a major load on the system.
You have 10 process all telling the drivers to keep seeking
about through the disks.
Add /etc/login.
Is there any way to stop what is below ?
As posted by y...@dgtu.donetsk.ua
>
>This script freeze my 3.1-RELEASE box.
>I can't make any connection with my box, also from console.
>
> cut here ---
>#! /bin/sh
>
>for j in 1 2 3 4 5 6 7 8 9 10
>do
>echo -n $j
>nohup sh -c 'while :; do fin
22 matches
Mail list logo
