Julian Elischer wrote:
> On Fri, 21 Feb 2003, Terry Lambert wrote:
> > Dan's non-atomicity assumption on renames is incorrect.
[ ... ]
> > I think that a workaround would be to comment the directory fsync()
> > code out of qmail, which apparently thinks it's running on extfs
> > or an async mounted
Kirk McKusick wrote:
> Yevgeniy Aleynikov wrote:
> > As pointed by Ken - we do have alot of file renames (qmail).
> > But 2-nd solution, directory-only rename serialization, probably
> > won't affect performance as much.
> >
> > But i believe it's not
On Fri, 21 Feb 2003, Terry Lambert wrote:
> Yevgeniy Aleynikov wrote:
> > As pointed by Ken - we do have alot of file renames (qmail).
> > But 2-nd solution, directory-only rename serialization, probably won't
> > affect performance as much.
> >
> > But i believe it's not only us who's gonna ha
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: bleh. Re: ufs_rename panic
Yevgeniy Aleynikov wrote:
> As pointed by Ken - we do have alot of file renames (qmail).
> But 2-nd solution, directory-only rename serialization, probably
> won't affect performanc
Yevgeniy Aleynikov wrote:
> As pointed by Ken - we do have alot of file renames (qmail).
> But 2-nd solution, directory-only rename serialization, probably won't
> affect performance as much.
>
> But i believe it's not only us who's gonna have problem when exploit
> code will be known by everybody
OTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: bleh. Re: ufs_rename panic
X-ASK-Info: Confirmed by User
Just reminder that this problem is local kernel panic DoS (which can do
filesystem corruption) with very simple trigger code and i
> McKusick wrote:
> The potentially slow, but utterly effective way to fix this race
> is to only allow one rename at a time per filesystem.
Can we serialize unprivileged renames per mount as an alternate work around?
Later
Mark Hittinger
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL P
, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: bleh. Re: ufs_rename panic
X-ASK-Info: Confirmed by User
Just reminder that this problem is local kernel panic DoS (which can do
filesystem corruption) with very simple trigger code and it still exists.
Just reminder that this problem is local kernel panic DoS (which can do
filesystem corruption) with very simple trigger code and it still exists.
And it's been almost 2 years since i wrote about it.
Workaround (commenting out panic call) doesnt fix the problem.
Server still crashes (not so ofte
Thanks. I run the mklink.sh script on FreeBSD 4.3, it simply rejects
by saying "head: l0: File name too long". So I guess it does not even
reach the kernel yet.
-Zhihui
On Fri, 19 Oct 2001, Yevgeniy Aleynikov wrote:
>
> FYI:
>
>
>http://www.securityfocus.com/cgi-bin/archive.pl?id=1&mid=221
FYI:
http://www.securityfocus.com/cgi-bin/archive.pl?id=1&mid=221337&start=2001-10-15&end=2001-10-21
(about how things done in Linux).
Zhihui Zhang wrote:
> (1) I am always wondering why not use a global rename lock so that there
> is only one rename operation in progress at any time. Th
Here's another stable panic (not very often but on different boxes too).
--
Yevgeniy Aleynikov
Infospace, Inc.
SysAdmin, USE
Work: (206)357-4594
SMP 2 cpus
IdlePTD 3039232
initial pcb at 2666a0
panicstr: ffs_valloc: dup alloc
panic messages:
---
panic: ffs_valloc: dup alloc
mp_lock = 0101;
On Sun, Oct 07, 2001 at 06:09:45PM -0700, Kris Kennaway wrote:
> On Fri, Oct 05, 2001 at 04:17:14PM -0700, Yevgeniy Aleynikov wrote:
>
> > And why FreeBSD security officer's email address always bounces my
> > mail?
>
> Don't know, it's apparently still working fine for others.
Wild guess:
On Fri, Oct 05, 2001 at 04:17:14PM -0700, Yevgeniy Aleynikov wrote:
> And why FreeBSD security officer's email address always bounces my
> mail?
Don't know, it's apparently still working fine for others.
Kris
msg29046/pgp0.pgp
Description: PGP signature
Well, I've gone through hell trying to fix the rename()/rmdir()/remove()
races and failed utterly. There are far more race conditions then even
my last posting indicated, and there are *severe* problems fixing NFS
to deal with even Ian's suggestion... it turns out that NFS's nfs_n
:
:It seems like there's no activity on this subject.
:This is local DoS, guys. if it gets on public (which is probably gonna
:be soon) everything everywhere will be crashing, and there's no stable
:fix ready.
:How can i help to accelerate this problem solution?
:
: And why FreeBSD security
It seems like there's no activity on this subject.
This is local DoS, guys. if it gets on public (which is probably gonna
be soon) everything everywhere will be crashing, and there's no stable
fix ready.
How can i help to accelerate this problem solution?
And why FreeBSD security officer's
On Wed, 3 Oct 2001, Ken Pizzini wrote:
> Zhihui Zhang <[EMAIL PROTECTED]> wrote:
> > (3) Matt says "For example, if you have two hardlinked files residing in
> > different directories both get renamed simultaniously, one of the
> > rename()s can fail even though there is no conflict
>
:The addition of the SOFTLOCKLEAF code is quite a major change, so
:it would be very useful if you could describe exactly what it does,
:what its semantics are, and how it fits into the rename problem.
Setting SOFTLOCKLEAF in namei will set the VSOFTLOCK flag in the
returned vnode (whethe
:The rename routine is probably the most convoluted in the entire file
:system code (FFS). Now that everybody's memory is fresh, I would like to
:ask something about it:
:
:(1) I am always wondering why not use a global rename lock so that there
:is only one rename operation in progress at an
The rename routine is probably the most convoluted in the entire file
system code (FFS). Now that everybody's memory is fresh, I would like to
ask something about it:
(1) I am always wondering why not use a global rename lock so that there
is only one rename operation in progress at any time
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>
>:This seems rather large compared to Ian Dowse's version.. Are you sure that
>:you're doing this the right way? Adding a whole new locking mechanism
>:when the simple VRENAME flag to be enough seems like a bit of overkill..
Matt addresses t
:The problems all arise from the fact that we unlock the source
:while we look up the destination, and when we return to relookup
:the source, it may have changed/moved/disappeared. The reason to
:unlock the source before looking up the destination was to avoid
:deadlocking against ourselves on a
The problems all arise from the fact that we unlock the source
while we look up the destination, and when we return to relookup
the source, it may have changed/moved/disappeared. The reason to
unlock the source before looking up the destination was to avoid
deadlocking against ourselves on a lock
:
:Matt Dillon wrote:
:> Here is the latest patch I have. It appears to completely solve the
:> problem. I have shims in unionfs and nfs for the moment.
:
:This seems rather large compared to Ian Dowse's version.. Are you sure that
:you're doing this the right way? Adding a whole new
Matt Dillon wrote:
> Here is the latest patch I have. It appears to completely solve the
> problem. I have shims in unionfs and nfs for the moment.
This seems rather large compared to Ian Dowse's version.. Are you sure that
you're doing this the right way? Adding a whole new locking m
Here is the latest patch I have. It appears to completely solve the
problem. I have shims in unionfs and nfs for the moment.
The patch is against -stable.
* Implements SOFTLOCKLEAF namei() option
* Implements EAGAIN error & appropriate tsleep/retry code
* Universal fo
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>What I've done is add a SOFTLOCKLEAF capability to namei(). If set, and
>the file/directory exists, namei() will generate an extra VREF() on
>the vnode and set the VSOFTLOCK flag in vp->v_flag. If the vnode already
>has VSOFTL
Ok, I'm adding -hackers... another email thread got going in -committers.
Here is a patch set for -stable. It isn't perfect but it does appear
to solve the problem. The one case I don't handle right is if you have
a hardlinked file and two renames in two different directories o
29 matches
Mail list logo
