---559023410-21307229-931242446=:23200
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 6 Jul 1999, Arthur wrote:
> On Mon, 5 Jul 1999 23:53:29 +0100 (BST), Alan Cox
> <alan@lxorguk.ukuu.org.uk> wrote:
>
> >> I switch to 2.2.10-ac8 (RH 6.0) last night and saw that the slocate
> >> cron run every night was still active, consuming 100% CPU.
>
> >Interesting. 2.2.10ac8 has Al Viro's updates for FAT/VFAT including the
> >directory pointer caching, so that it should break here is very believable
>
> With 2.2.9mdk (Mandrake) I have the same problem with slocate.
Right. You do. It's a combination of my idiocy and idiocy of slocate
authors. Sigh... In case of root directory the second entry (fake "..")
got an d_off (offset of the next entry) equal to 0 *if* there were
additional entries successfully filled by getdents(). My idiocy.
Now, authors of slocate, in their infinite wisdom, decided to do
seekdir after each readdir. Which means that they call getdents (on a
decently-sized buffer) for each bloody offset. It is idiocy. Number of
getdents() calls is 2 orders of magintude higher than it should be.
Combination of those bogosities gave an infinite loop.
Fix for FAT attached (it's against -ac8, with 2.2.9 it will get a
line numbers offset but will apply fine).
As for slocate... Look for seekdir(recdir, telldir()); and shoot
it. Dunno if the author reads l-k (he didn't leave an address in the
source), but just in case: seekdir() is *NOT* needed if you read
sequentially. Just as fseek(); is not needed for files in the similar
case.
Down, not across...
Al
---559023410-21307229-931242446=:23200
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=foo
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.10.9907060227260.23200@weyl.math.psu.edu>
Content-Description:
Content-Disposition: attachment; filename=foo
LS0tIGZzL2ZhdC9kaXIuYwlUdWUgSnVsICA2IDAxOjQ0OjQ1IDE5OTkNCisr
KyBmcy9mYXQvZGlyLmMubmV3CVR1ZSBKdWwgIDYgMDE6NTA6MzAgMTk5OQ0K
QEAgLTMxMCw2ICszMTAsOCBAQA0KIAljaGFyIGJ1Zm5hbWVbMTRdOw0KIAlj
aGFyICpwdG5hbWUgPSBidWZuYW1lOw0KIAlpbnQgZG90b2Zmc2V0ID0gMDsN
CisJdW5zaWduZWQgbG9uZyAqZnVycmZ1ID0gJmxwb3M7DQorCXVuc2lnbmVk
IGxvbmcgZHVtbXk7DQogDQogCWNwb3MgPSBmaWxwLT5mX3BvczsNCiAvKiBG
YWtlIC4gYW5kIC4uIGZvciB0aGUgcm9vdCBkaXJlY3RvcnkuICovDQpAQCAt
MzIwLDggKzMyMiwxMSBAQA0KIAkJCWNwb3MrKzsNCiAJCQlmaWxwLT5mX3Bv
cysrOw0KIAkJfQ0KLQkJaWYgKGNwb3MgPT0gMikNCisJCWlmIChjcG9zID09
IDIpIHsNCisJCQlkdW1teSA9IDI7DQorCQkJZnVycmZ1ID0gJmR1bW15Ow0K
IAkJCWNwb3MgPSAwOw0KKwkJfQ0KIAl9DQogCWlmIChjcG9zICYgKHNpemVv
ZihzdHJ1Y3QgbXNkb3NfZGlyX2VudHJ5KS0xKSkNCiAJCXJldHVybiAtRU5P
RU5UOw0KQEAgLTQ1NSw3ICs0NjAsNyBAQA0KIAlpZiAoIWxvbmdfc2xvdHN8
fHNob3J0bmFtZXMpIHsNCiAJCWlmIChib3RoKQ0KIAkJCWJ1Zm5hbWVbaV0g
PSAnXDAnOw0KLQkJaWYgKGZpbGxkaXIoZGlyZW50LCBidWZuYW1lLCBpLCBs
cG9zLCBpbnVtKSA8IDApDQorCQlpZiAoZmlsbGRpcihkaXJlbnQsIGJ1Zm5h
bWUsIGksICpmdXJyZnUsIGludW0pIDwgMCkNCiAJCQlnb3RvIEZpbGxGYWls
ZWQ7DQogCX0gZWxzZSB7DQogCQljaGFyIGxvbmduYW1lWzI3NV07DQpAQCAt
NDY2LDExICs0NzEsMTIgQEANCiAJCQltZW1jcHkoJmxvbmduYW1lW2xvbmdf
bGVuKzFdLCBidWZuYW1lLCBpKTsNCiAJCQlsb25nX2xlbiArPSBpOw0KIAkJ
fQ0KLQkJaWYgKGZpbGxkaXIoZGlyZW50LCBsb25nbmFtZSwgbG9uZ19sZW4s
IGxwb3MsIGludW0pIDwgMCkNCisJCWlmIChmaWxsZGlyKGRpcmVudCwgbG9u
Z25hbWUsIGxvbmdfbGVuLCAqZnVycmZ1LCBpbnVtKSA8IDApDQogCQkJZ290
byBGaWxsRmFpbGVkOw0KIAl9DQogDQogUmVjRW5kOg0KKwlmdXJyZnUgPSAm
bHBvczsNCiAJZmlscC0+Zl9wb3MgPSBjcG9zOw0KIAlnb3RvIEdldE5ldzsN
CiBFT0RpcjoNCg==
---559023410-21307229-931242446=:23200--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/