Second attempt, the first one failed due to stupid setup of ISP and the
usage of mail-abuse.org which blocks anything that has no reverse DNS
lookup. So some of my messages (about 20%) get lost and I have to resend
them when I feel it's been too quiet :)
---------- Forwarded message ----------
Date: Mon, 4 Dec 2000 13:43:20 +0000 (GMT)
From: Tigran Aivazian <[email protected]>
To: Christopher Yeoh <[email protected]>
Cc: Linus Torvalds <[email protected]>, [email protected]
Subject: Re: [PATCH] Attempt to hard link across filesystems results in
un-unmountable filesystem
On Tue, 21 Nov 2000, Christopher Yeoh wrote:
>
> In 2.4-test11 attempting to hard link a file across filesystems (the
> link does fail correctly) results in one of the filesystems (the one
> the hard link was to be created on) to be in a state such that it
> can't be unmounted.
>
> The attached patch fixes this problem.
Hi Christopher,
It is true that your patch fixes the problem as reported but let us look
one step deeper into the problem. Linux supports multiply mounted
instances of a filesystem and the check in sys_link() comparing the
mountpoints would refuse (with cross-device link error) linking between
them. This is correct. However, one level down, inside vfs_link() we also
check for ->i_dev match and that seems unnecessary, now that (with your
patch) link(2) would work correctly anyway.
Therefore, I propose a slightly modified (tested under
2.4.0-test12-pre4) version of the patch. What do you think? My philosophy
is -- since you made this feature work properly you should make it work
efficiently too and that means removing redundant code.
Regards,
Tigran
--- linux/fs/namei.c Mon Dec 4 08:43:35 2000
+++ work/fs/namei.c Mon Dec 4 12:34:24 2000
@@ -1551,10 +1551,6 @@
if (error)
goto exit_lock;
- error = -EXDEV;
- if (dir->i_dev != inode->i_dev)
- goto exit_lock;
-
/*
* A link to an append-only or immutable file cannot be created.
*/
@@ -1611,7 +1607,7 @@
goto out;
error = -EXDEV;
if (old_nd.mnt != nd.mnt)
- goto out;
+ goto out2;
new_dentry = lookup_create(&nd, 0);
error = PTR_ERR(new_dentry);
if (!IS_ERR(new_dentry)) {
@@ -1619,6 +1615,7 @@
dput(new_dentry);
}
up(&nd.dentry->d_inode->i_sem);
+out2:
path_release(&nd);
out:
path_release(&old_nd);
> Second attempt, the first one failed due to stupid setup of ISP and the
> usage of mail-abuse.org which blocks anything that has no reverse DNS
> lookup. So some of my messages (about 20%) get lost and I have to resend
> them when I feel it's been too quiet :)
mail-abuse doesnt do this. One thing it does do however is provide block lists
of addresses where the ISP has said 'this should not be direct mail sources'.
On Mon, 4 Dec 2000, Alan Cox wrote:
> > Second attempt, the first one failed due to stupid setup of ISP and the
> > usage of mail-abuse.org which blocks anything that has no reverse DNS
> > lookup. So some of my messages (about 20%) get lost and I have to resend
> > them when I feel it's been too quiet :)
>
> mail-abuse doesnt do this. One thing it does do however is provide block lists
> of addresses where the ISP has said 'this should not be direct mail sources'.
Alan, I thank you for sparing a minute to enlighten me. But the _only_
thing I do not understand still (and it appears to be critical) is why it
only happens sometimes but not others? i.e. in both times I dialled to
btconnect.com and faked From: [email protected] (via pine(1) setup).
Sometimes it gets through to linux-kernel and sometimes it does not. E.g.
this second attempt was sent under exactly the same conditions as the
first one. So I was justified in assuming (wrongly as you say) that
something external to me was different and the only external thing was
dynamic ip address assigned to the ISDN interface of the router. (so I
made the assumption that in one case it was lookupable and in another it
was not, maybe this assumption is totally broken, i.e. nothing would work
if I was _ever_ assigned such address)
So, I am still not wiser as to what to do (other than admit to being
@btconnect.com :) to make all my messages safely reach
linux-kernel. Btconnect.com people also seems to have absolutely no clue
so far, unfortunately (probably both me and they are too lazy to (re)read
Stevence's TCP/IP Illustrated Volume I and understand how DNS and SMTP are
supposed to cooperate).
Regards,
Tigran
On Mon, 4 Dec 2000, Tigran Aivazian wrote:
> It is true that your patch fixes the problem as reported but let us look
> one step deeper into the problem. Linux supports multiply mounted
> instances of a filesystem and the check in sys_link() comparing the
> mountpoints would refuse (with cross-device link error) linking between
> them. This is correct. However, one level down, inside vfs_link() we also
> check for ->i_dev match and that seems unnecessary, now that (with your
> patch) link(2) would work correctly anyway.
>
> Therefore, I propose a slightly modified (tested under
> 2.4.0-test12-pre4) version of the patch. What do you think? My philosophy
> is -- since you made this feature work properly you should make it work
> efficiently too and that means removing redundant code.
Tigran, think about the uses from knfsd.
Yo Tigran!
On Mon, 4 Dec 2000, Tigran Aivazian wrote:
> Second attempt, the first one failed due to stupid setup of ISP and the
> usage of mail-abuse.org which blocks anything that has no reverse DNS
> lookup.
Mail-abuse.org does nothing with reverse DNS. Many that hate spam
choose to refuse mail with no reverse DNS on theire own.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
[email protected] Tel:+1(541)382-8588 Fax: +1(541)382-8676
On Mon, 4 Dec 2000, Alexander Viro wrote:
> Tigran, think about the uses from knfsd.
Yes, you are right. I thought I grepped for all usages of vfs_link but
looks like I did not, i.e. when sending the patch I was sure that sys_link
is the only user of vfs_link but now that you pointed it out I clearly see
why my suggestion was wrong.
Thank you,
Tigran