this works fine in pre8. thanks all!
Joseph Cheek wrote:
> copying files off a loopback-mounted vfat filesystem exposes this bug.
> test11 worked fine.
>
> loop.o built as module. this hard crashes the machine, every time
> [PIII-450]. i don't know how to debug this, is there a FAQ?
>
> [tran
On Sat, 9 Dec 2000, Mikulas Patocka wrote:
>
> I did a test. I disabled readahead except for reading all 4 buffers in
> map_4sectors.
>
> I observed 14% slowdown on walking directories with find and 4% slowdown
> on grepping one my working directory (10M, 281 files).
>
> If you can't make it
On Sat, 9 Dec 2000, Alexander Viro wrote:
> On Sat, 9 Dec 2000, Andries Brouwer wrote:
>
> > On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
> >
> > > > @@ -1210,7 +1204,6 @@
> > > [breada()]
> > > Umm... why do we keep it, in the first place? AFAICS the only
> > > in-tree use
Linus Torvalds <[EMAIL PROTECTED]> writes:
> > Modulo the comments above - fine with me. However, there is stuff in
> > drivers/md that I don't understand. Ingo, could you comment on the use of
> > ->b_end_io there?
>
> I already sent him mail about it for the same reason.
How about sendi
On Sat, 9 Dec 2000, Alexander Viro wrote:
> Fine
> > - atomic_inc(&bh->b_count);
>
> Why? It's cleaner the old way - why bother postponing that until we
> lock the thing?
I had a rule: we always do the "lock_buffer()" and "b_count increment"
together with setting "b_end_i
modules/2.4.0-test12-pre6-LVM-REISERFS/ (specified)
-m /boot/System.map-2.4.0-test12-pre6-LVM-REISERFS (specified)
No modules in ksyms, skipping objects
Unable to handle kernel paging request at virtual address 0228
swapper(0): Oops 1
pc = [] ra = [] ps = 0007
Using defaults fr
On Fri, 8 Dec 2000, Alexander Viro wrote:
> BTW, what do you think about the following:
> * add_to_page_cache() is not exported and never used. Kill?
I have my eye on that for execute-in-place of romfs from real ROM chips -
making up struct pages for parts of the ROM chips and inserting th
Date:Sat, 9 Dec 2000 00:45:51 -0800 (PST)
From: Linus Torvalds <[EMAIL PROTECTED]>
out:
-if (nr) {
-ll_rw_block(WRITE, nr, arr);
-} else {
-UnlockPage(page);
-}
+UnlockPage(page);
ClearPageUptodate(page);
On Sat, 9 Dec 2000, Andries Brouwer wrote:
> On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
>
> > > @@ -1210,7 +1204,6 @@
> > [breada()]
> > Umm... why do we keep it, in the first place? AFAICS the only
> > in-tree user is hpfs_map_sector() and it doesn't look like we real
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
> > @@ -1210,7 +1204,6 @@
> [breada()]
> Umm... why do we keep it, in the first place? AFAICS the only
> in-tree user is hpfs_map_sector() and it doesn't look like we really
> need it there. OTOH, trimming the buffer.c down is
On Sat, 9 Dec 2000, Linus Torvalds wrote:
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
>
> If somebody wants to run with this, please try it out, but realize that
> it's
On Sat, 9 Dec 2000, Linus Torvalds wrote:
>
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
Call me stupid [ Chorus: "You're stupid, Linus" ], but I actually compiled
and b
On Fri, 8 Dec 2000, Alexander Viro wrote:
> On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
> > Looking more at this issue, I suspect that the easiest pretty solution
> > that everybody can probably agree is reasonable is to either pass down the
> > end-of-io callback to ll_rw_block as you suggested
On Fri, 8 Dec 2000, Linus Torvalds wrote:
> Looking more at this issue, I suspect that the easiest pretty solution
> that everybody can probably agree is reasonable is to either pass down the
> end-of-io callback to ll_rw_block as you suggested, or, preferably by just
> forcing the _caller_ to
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> I'm quite aware of that fact ;-) However, you said
>
>On the other hand, I have this suspicion that there is an even simpler
>solution: stop using the end_buffer_io_sync version for writes
>altogether.
>
> If that happens (i.e. if wri
On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2000, Alexander Viro wrote:
> >
> > Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> > but that will make for somewhat bigger patch. Hey, _you_ are in position
> > to change the locking rules, freeze or
Linus Torvalds wrote:
>
> On Fri, 8 Dec 2000, Daniel Phillips wrote:
> >
> > [ flush-buffers taking the page lock ]
> >
> > This is great when you have buffersize==pagesize. When there are
> > multiple buffers per page it means that some of the buffers might have
> > to wait for flushing just be
On Fri, 8 Dec 2000, Daniel Phillips wrote:
>
> [ flush-buffers taking the page lock ]
>
> This is great when you have buffersize==pagesize. When there are
> multiple buffers per page it means that some of the buffers might have
> to wait for flushing just because bdflush started IO on some oth
On Fri, 08 Dec 2000, Linus Torvalds wrote:
> Btw, I also think that the dirty buffer flushing should get the page lock.
> Right now it touches the buffer list without holding the lock on the page
> that the buffer is on, which means that there is really nothign that
> prevents it from racing with
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> but that will make for somewhat bigger patch. Hey, _you_ are in position
> to change the locking rules, freeze or not, so if it's OK with you...
No.
Read the code a bit mo
On Fri, 8 Dec 2000, Linus Torvalds wrote:
> It's really only __block_prepare_write() that can mark the buffers for
> sync writes, and even that case is fairly bogus: it really only wants to
> mark the non-upto-date buffers that it wants to _read_ for sync IO, it
> just "knows" that it is ok to
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Fix: postpone changing ->b_end_io until the call of ll_rw_block(); if by
> the time of ll_rw_block() some fragments will still have IO in progress -
> wait on them.
>
> Comments?
Yes.
On the other hand, I have this suspicion that there is an even
Folks, see if the following patch helps. AFAICS it closes a pretty real
race - we could call block_write_full_page() for a page that has sync
IO in progress and blindly change ->b_end_io callbacks on the bh with
pending requests. With a little bit of bad luck they would complete before
we got to l
On Thu, Dec 07, 2000 at 09:59:18PM -0500, Alexander Viro wrote:
> On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> > > BTW, could we finally lose mpx(2)?
> >
> > Maybe we lost it - I find sys_mpx only in a comment in arch/arm/kernel/calls.S
>
> Sure, but man2/mpx.2 is alive and well...
manpages-de
I'm doing some massive grepping (basically, audit of page locking),
but nothing relevant so far. There was some catch (aside of documenting
the thing and finding several completely unrelated buglets):
* ramfs_writepage() doesn't UnlockPage(). Deadlock.
* udf_adinicb_writepa
[EMAIL PROTECTED] said:
> Can you test some more? In particular, I'd love to hear if this
> happens with vfat even without loopback, or with loopback even without
> vfat (make an ext2 filesystem or similar instead). That woul dnarrow
> down the bug further.
Loopback-mounted iso9660 does it too
Linus Torvalds wrote:
>
> It's not a new bug - it's an old bug that apparently is uncovered by a
> new stricter test.
>
> Apparently loopback unlocks an already unlocked page - which has always
> been a serious offense, but has never been detected before.
>
>
On Thu, 07 Dec 2000 17:23:51 -0800,
Joseph Cheek <[EMAIL PROTECTED]> wrote:
>i'll check it out. i'm compiling ksymoops now, is there a way to get it to
>work without a static libbfd? all i've got is a libbfd.so, and i'm going to
>need to recompile binutils if i must have a libbfd.a.
ksymoops/M
On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> > BTW, if you still have 1.7, 1.10, 1.13 and 1.14...
>
> See ftp://ftp.cwi.nl/pub/aeb/manpages/ (will soon disappear again).
Got them, thanks.
> > BTW, could we finally lose mpx(2)?
>
> Maybe we lost it - I find sys_mpx only in a comment in arch
> BTW, if you still have 1.7, 1.10, 1.13 and 1.14...
See ftp://ftp.cwi.nl/pub/aeb/manpages/ (will soon disappear again).
> BTW, could we finally lose mpx(2)?
Maybe we lost it - I find sys_mpx only in a comment in arch/arm/kernel/calls.S
Andries
-
To unsubscribe from this list: send the line "u
s an old bug that apparently is uncovered by a
> new stricter test.
>
> Apparently loopback unlocks an already unlocked page - which has always
> been a serious offense, but has never been detected before.
>
> test12-pre6+ detects it, and thus the BUG().
>
> Your stack trace isn
i'll check it out. i'm compiling ksymoops now, is there a way to get it to
work without a static libbfd? all i've got is a libbfd.so, and i'm going to
need to recompile binutils if i must have a libbfd.a.
Linus Torvalds wrote:
> Your stack trace isn't symbolic (see Documentation/oops-tracing.t
loopback unlocks an already unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the BUG().
Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so
it's impossible to debug, but it's already i
On Thu, 07 Dec 2000 14:42:38 -0800,
Joseph Cheek <[EMAIL PROTECTED]> wrote:
>loop.o built as module. this hard crashes the machine, every time
>[PIII-450]. i don't know how to debug this, is there a FAQ?
linux/Documentation/oops-tracing.txt
-
To unsubscribe from this list: send the line "unsu
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
[transcribed by hand]:
# mount -o loop /tmp/cdboot.288 /mnt/cd
# cd /mnt/cd
On Thu, 7 Dec 2000, Andries Brouwer wrote:
> On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
>
> > Al, currently walking through the /usr/share/man/man2 and swearing silently...
>
> Swearing? At the POSIX decisions or at the man page quality?
Mostly at the out-of-sync/not-all
On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
> Al, currently walking through the /usr/share/man/man2 and swearing silently...
Swearing? At the POSIX decisions or at the man page quality?
In the latter case, additions and corrections are very welcome.
Make sure that you have 1.
On Thu, Dec 07, 2000 at 08:23:59AM -0500, Alexander Viro wrote:
>
> Oh, lovely - where the hell had the following come from?
> % man truncate
> ...
>EINVAL The pathname contains a character with the high-
> order bit set.
> ...
> Andries, would you mind removing that, er
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> yet. So far you only said that a different implementation, i.e. a
> different place to put the checks, is preferrable.
-EPERM returned by permission() if we ask for write access to immutable.
Al, currently walking through the /usr/share/man/man2 an
On Thu, 7 Dec 2000, Alexander Viro wrote:
> On Thu, 7 Dec 2000, Tigran Aivazian wrote:
>
> > The rationale for being compatible with 4.4BSD on append-only but not on
> > immutable is -- for immutable we can do the test by means of permission()
> > fast but for append-only we would need an extra i
On Wed, Dec 06, 2000 at 08:47:23PM -0500, Wakko Warner wrote:
> I'm glad to say that this is the first 2.4 kernel that works on my noritake
> alpha with a pci-pci bridge.
>
> I have a small problem. If I reboot, the srm console can't boot from dka0.
> Doing a: show dev
> doesn't list any of the
On Thu, 7 Dec 2000, Alexander Viro wrote:
> So correct solution may very well be to change the return value of
> permission(9). FWIW, MAY_TRUNCATE might be a good idea - notice that
> knfsd already has something like that. It makes sense for directories,
> BTW - having may_delete() drop the IS_APP
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> The rationale for being compatible with 4.4BSD on append-only but not on
> immutable is -- for immutable we can do the test by means of permission()
> fast but for append-only we would need an extra if() above permission so
> let's just be BSD-compat
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> a) we don't hit that test because permission takes care of it (for
> regulars/dirs/symlinks but here only regulars are important)
omit what is in brackets but everything in email and the patch itself are
valid and tested. The detail in bracket above wa
On Wed, 6 Dec 2000, Alexander Viro wrote:
> On Wed, 6 Dec 2000, Linus Torvalds wrote:
> > Why remove the EROFS test?
>
> there, so if it's not a regular file we die before the call of permission(),
> if it is and fs is readonly - we get -EROFS from permission() and die
> there. In either case we d
I'm glad to say that this is the first 2.4 kernel that works on my noritake
alpha with a pci-pci bridge.
I have a small problem. If I reboot, the srm console can't boot from dka0.
Doing a: show dev
doesn't list any of the hard drives in the machine.
doing an init causes it to reset and find all
Andrew Morton wrote:
> Wakko Warner wrote:
> >
> > > - pre6:
> > > - Andrew Morton: exec_usermodehelper fixes
> >
> > pre4 oopsed all over the place on my alpha with modules and autoloading
> > turned on as soon as it mounted / and freed unused memory. I take it this
> > was seen on i386 a
> From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
>
...
> Now, this is with a bog-standard PIIX irq router, so we
> definitely know
> that we have the pirq table parsing right. I even have unofficial
> confirmation from intel engineers on this.
>
> But I see something obviously wrong there: you
Erik Mouw wrote:
> On Wed, Dec 06, 2000 at 11:38:30AM -0800, Linus Torvalds wrote:
>
>> But I see something obviously wrong there: you have busmaster disabled.
>>
>> Looking into the UHCI controller code, I notice that neither UHCI driver
>> actually does the (required)
>>
>> pci_set_mast
Jeff Garzik wrote:
> eh? It's self-evident from Erik's patch that pci_enable_device's return
> call is already being tested, thus you only need to add a call to
> pci_set_master.
Sorry. I'll shut up now and go back to doing something
I actually am somewhat knowledgable about -- namely, testi
Miles Lane wrote:
>
> Hmm. Your patch doesn't test whether pci_enable_device(dev)
> was successful, does it?
eh? It's self-evident from Erik's patch that pci_enable_device's return
call is already being tested, thus you only need to add a call to
pci_set_master.
Jeff
--
Jeff Garzik
On Wed, Dec 06, 2000, Miles Lane <[EMAIL PROTECTED]> wrote:
> Hmm. Your patch doesn't test whether pci_enable_device(dev)
> was successful, does it?
Umm, it does. If pci_enable_device wasn't successful, it returns -ENODEV.
Your patch below calls pci_set_master if enabling the device fails and
t
Hmm. Your patch doesn't test whether pci_enable_device(dev)
was successful, does it?
I think what you want is:
diff -u --new-file drivers/usb/uhci.c~ drivers/usb/uhci.c
--- drivers/usb/uhci.c~ Tue Dec 5 23:55:38 2000
+++ drivers/usb/uhci.c Wed Dec 6 14:50:00 2000
@@ -2380,8 +2380,10 @@
On Wed, 6 Dec 2000, Linus Torvalds wrote:
>
>
> On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> >
> > This patch combines your previous patch with 2 changes I have just
> > suggested. Both changes are obvious (and correct).
>
> Why remove the EROFS test?
Tigran has a point - permission() does
Erik Mouw wrote:
>
> On Wed, Dec 06, 2000 at 11:38:30AM -0800, Linus Torvalds wrote:
> > But I see something obviously wrong there: you have busmaster disabled.
> >
> > Looking into the UHCI controller code, I notice that neither UHCI driver
> > actually does the (required)
> >
> > pci_set_
On Wed, Dec 06, 2000 at 11:38:30AM -0800, Linus Torvalds wrote:
> But I see something obviously wrong there: you have busmaster disabled.
>
> Looking into the UHCI controller code, I notice that neither UHCI driver
> actually does the (required)
>
> pci_set_master(dev);
>
> Please add tha
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
>
> This patch combines your previous patch with 2 changes I have just
> suggested. Both changes are obvious (and correct).
Why remove the EROFS test?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Wed, 6 Dec 2000, Erik Mouw wrote:
> >
> > Can you tell me what device it is that doesn't work for you?
>
> The USB controller. That's device 00:07.2:
>
> 00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller
>(prog-if 00 [UHCI])
> Control: I/O+ Mem- BusM
On Wed, Dec 06, 2000 at 10:38:51AM -0800, Linus Torvalds wrote:
> On Wed, 6 Dec 2000, Erik Mouw wrote:
> > So at first the PCI code can't allocate an IRQ for devices 00:00.1
> > (audio), 00:07.2 (USB), and 00:09.0 (winmodem), but after the audio and
> > USB modules get inserted, IRQ 5 and 11 get a
On Wed, 6 Dec 2000, Erik Mouw wrote:
>
> So at first the PCI code can't allocate an IRQ for devices 00:00.1
> (audio), 00:07.2 (USB), and 00:09.0 (winmodem), but after the audio and
> USB modules get inserted, IRQ 5 and 11 get allocated.
No, the irq stuff is a two-stage process: at first it on
On Tue, Dec 05, 2000 at 11:25:55PM -0800, Linus Torvalds wrote:
> Concering the PCI irq routing fixes in particular, I'd ask people with
> laptops to start testing their kernels with PnP OS set to "yes" in the
> BIOS setup. We shoul dbe at a stage where it should basically work all the
> time, and
Tobias Ringstrom wrote:
> The way I see it, 2.4.0-test12-pre6 is just a much longer name for 2.4.0.
> Keep going like this and we may end up calling you Linus "Santa" Torvalds!
> It has a nice ring to it, don't you think? :-) Or should that be *-<:-)
I appr
> time, and it would be interesting to hear about cases that we don't handle
> right.
It works fine here on a Mitac laptop (the one that needed a Win98
warm-boot a few weeks ago), but it is quite noisy about IRQs that are also
used for other devices. (PCI: The same IRQ used for device 00:08.0)
Wakko Warner wrote:
>
> > - pre6:
> > - Andrew Morton: exec_usermodehelper fixes
>
> pre4 oopsed all over the place on my alpha with modules and autoloading
> turned on as soon as it mounted / and freed unused memory. I take it this
> was seen on i386 as well?
No... The problems showed t
> - pre6:
> - Andrew Morton: exec_usermodehelper fixes
pre4 oopsed all over the place on my alpha with modules and autoloading
turned on as soon as it mounted / and freed unused memory. I take it this
was seen on i386 as well?
Will try pre6.
--
Lab tests show that use of micro$oft cause
s not just a good idea, it is imperative and Linux already does that --
> so we can drop that check from if() unconditionally, which is what the
> patch below does).
>
> Tested under 2.4.0-test12-pre6.
>
> Regards,
> Tigran
>
> --- linux/fs/open.c Thu Oct 26 16:11:21
On Wed, 6 Dec 2000, Alexander Viro wrote:
> They are not Linux-specific (check where they came from), so I would rather
> check 4.4BSD and SuSv2[1] be damned. I'll look it up tomorrow, right now I'm
> going down. Sorry.
4.4BSD (FreeBSD 4.2-release) returns EPERM for truncate on immutable (schg
or
that check from if() unconditionally, which is what the
patch below does).
Tested under 2.4.0-test12-pre6.
Regards,
Tigran
--- linux/fs/open.c Thu Oct 26 16:11:21 2000
+++ work/fs/open.c Wed Dec 6 08:05:43 2000
@@ -102,7 +102,12 @@
goto out;
inode = nd.dentry
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> > error = -EPERM;
> > if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
> > goto dput_and_out;
>
> also, while we are here -- are you sure that EPERM is a good idea for
> IS_IMMUTABLE(inode
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> error = -EPERM;
> if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
> goto dput_and_out;
also, while we are here -- are you sure that EPERM is a good idea for
IS_IMMUTABLE(inode)? Other parts of Linux return EACCES in this
case. Ma
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> minutes ago... maybe you could merge it into yours and re-send to Linus?
here is the merged patch:
--- linux/fs/open.c Thu Oct 26 16:11:21 2000
+++ work/fs/open.c Wed Dec 6 07:38:30 2000
@@ -102,7 +102,12 @@
goto out;
Oh, Alexander your patch conflicts (well, not strictly but causes
patch(1) to spew warnings) with the one I just wanted to send to Linus 10
minutes ago... maybe you could merge it into yours and re-send to Linus?
Mine is obvious, see below (vfs_permission does have enough to fail with
EROFS on a
ext2_get_block() should return -EFBIG if the block number is
too large for our block size. It returns -EIO and prints a warning
right now. Fix: don't generate bogus warnings (we can legitimately
get larger-than-maximum arguments; there is no way in hell VFS or VM
could know the ext2-specif
truncate() and ftruncate() return values are different from the
POSIX requirements and from the values returned by other Unices (and from
our own manpages, BTW). Trivial fix follows. Rationale: see truncate(2),
ftruncate(2), POSIX or try to call the thing on other Unices.
Please,
If get_block() fails in block_prepare_write() we should zero
the blocks we've allocated and mark them dirty. We don't (i.e. we leave
the random junk in file in that case). Fix: do it. Moreover, if
->prepare_write() fails generic_file_write() is not going to write the user's
data into that
ext2_update_inode() marks the filesystems as having large files
if there the file becomes too large for old driver (2.2 one). Unfortunately,
it gets the limit wrong - it's not 2^32, it's 2^31. So we should check
for ->i_size_high being non zero _or_ ->i_size having bit 31 set. Please,
appl
On Tue, 5 Dec 2000, Linus Torvalds wrote:
>
> Ok, I almost called this the final test12, but I wanted to get some more
> feedback on the keyboard controller stuff and PCI irq routing.
Linus, could you apply the following bunch of fixes (split into separate
emails):
* dentry leak upon
Ok, I almost called this the final test12, but I wanted to get some more
feedback on the keyboard controller stuff and PCI irq routing.
The biggest part of this is the budding parisc stuff, but it's unlikely
that we'll see full parisc support in 2.4.0 - the remaining pieces that
actually touch g
78 matches
Mail list logo
