Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Tue, Dec 18, 2007 at 06:04:58PM -0800, Andrew Morton wrote: > Nobody seems to look after hppfs. I'll resend the fat and hostfs patches to > maintainers for a review, please. It's mine - I'll take a look at it. Jeff -- Work email - jdike at linux dot intel dot com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Wed, 19 Dec 2007 01:22:21 + David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > - inode = ERR_PTR(ret);
> > > + return NULL;
> > > } else {
> > > unlock_new_inode(inode);
> > > }
> > >
> >
> > Yup.
>
> Nope. The correct fix is to make the various callers use IS_ERR() to check
> the result of this function rather than checking for a NULL return.
>
> > David, this is concerning. More such error-path bugs in that code will take
> > years and years to get found and fixed.
>
> Yes, I know. I've looked over the patches several times, however I know there
> may be bugs in there because I may have made assumptions about what I've
> written that cause me to overlook things. It's a danger of checking your own
> code:-(
>
> > The best way to eliminate them is a line-by-line re-review of the patchset.
>
> And ideally by someone other than me. Some of them have been reviewed by
> other people, but I'm not sure that all have.
>
> However, I've just had another look through. ISOFS appears to be the only one
> in which I'd missed updating the callers. I've sent you a patch for it.
>
> Note that I expressed reservations about three filesystems in the cover note
> (FAT, HPPFS and HOSTFS), but nothing seems to have come of it.
>
Nobody seems to look after hppfs. I'll resend the fat and hostfs patches to
maintainers for a review, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Dec 19, 2007 9:22 AM, David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > - inode = ERR_PTR(ret);
> > > + return NULL;
> > > } else {
> > > unlock_new_inode(inode);
> > > }
> > >
> >
> > Yup.
>
> Nope. The correct fix is to make the various callers use IS_ERR() to check
> the result of this function rather than checking for a NULL return.
>
> > David, this is concerning. More such error-path bugs in that code will take
> > years and years to get found and fixed.
>
> Yes, I know. I've looked over the patches several times, however I know there
> may be bugs in there because I may have made assumptions about what I've
> written that cause me to overlook things. It's a danger of checking your own
> code:-(
>
> > The best way to eliminate them is a line-by-line re-review of the patchset.
>
> And ideally by someone other than me. Some of them have been reviewed by
> other people, but I'm not sure that all have.
>
> However, I've just had another look through. ISOFS appears to be the only one
> in which I'd missed updating the callers. I've sent you a patch for it.
>
> Note that I expressed reservations about three filesystems in the cover note
> (FAT, HPPFS and HOSTFS), but nothing seems to have come of it.
>
Hi,
The oops is at iput, I use 'return NULL ' is because I don't want to
change the the behaviour of iput in fs/inode.c.
Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > - inode = ERR_PTR(ret);
> > + return NULL;
> > } else {
> > unlock_new_inode(inode);
> > }
> >
>
> Yup.
Nope. The correct fix is to make the various callers use IS_ERR() to check
the result of this function rather than checking for a NULL return.
> David, this is concerning. More such error-path bugs in that code will take
> years and years to get found and fixed.
Yes, I know. I've looked over the patches several times, however I know there
may be bugs in there because I may have made assumptions about what I've
written that cause me to overlook things. It's a danger of checking your own
code:-(
> The best way to eliminate them is a line-by-line re-review of the patchset.
And ideally by someone other than me. Some of them have been reviewed by
other people, but I'm not sure that all have.
However, I've just had another look through. ISOFS appears to be the only one
in which I'd missed updating the callers. I've sent you a patch for it.
Note that I expressed reservations about three filesystems in the cover note
(FAT, HPPFS and HOSTFS), but nothing seems to have come of it.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
(Adding Dave Howells, his name is on iget-stop-isofs-from-using-read_inode.patch) On Tue, 18 Dec 2007 10:37:32 +0800, Dave Young said: > > I don't mind it failing the mount, but the oops seems excessive. I suspect > > that *somewhere* in that stack trace, we're wanting something like a > > > > if (!foo_ptr) > > return -EIO; > > > > but I admit not being competent enough to decide where that should be. > > > > Hi, > Could you please try the below patch: > > Signed-off-by: Dave Young <[EMAIL PROTECTED]> > > --- > fs/isofs/inode.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) With that patch applied, I took the ISO image (which I ended up reading on another machine and copying over the net to get a complete usable image), and dd'ed just the first 150M into another file, and tried to loopback mount it. And I got: # mount -o ro,loop /path/to/cd.partial.image /mnt/loop mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so And my dmesg says: [ 33.622073] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 33.622125] attempt to access beyond end of device [ 33.622129] loop0: rw=0, want=1284500, limit=30 [ 33.622133] ISOFS: unable to read i-node block Here is where we would oops before - now it errors out more reasonably: [ 33.622140] ISOFS: changing to secondary root [ 33.622148] attempt to access beyond end of device [ 33.622151] loop0: rw=0, want=1284508, limit=30 [ 33.622155] ISOFS: unable to read i-node block [ 33.622159] isofs_fill_super: get root inode failed So that fixes *this* bug. I looked in the -rc5-mm1 broken-out/, saw the vast multitudes of 'iget-stop--from-using' patches, and decided that somebody else will probably have to audit them for sanity. In the iget-* series, there's some 184 'return ERR_PTR(-E);' for some FOO, and 3 other uses: % grep ERR_PTR iget* | grep -v return iget-stop-isofs-from-using-read_inode.patch:+ inode = ERR_PTR(ret); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:+parent = ERR_PTR(-ENOMEM); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:-parent = ERR_PTR(-EACCES); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:-parent = ERR_PTR(-ENOMEM); isofs is the only place we don't return a constant 'ERR_PTR(-EFOO)', but cast somebody else's return value. I wish I understood what that tells us. ;) pgppwUchT0vXx.pgp Description: PGP signature
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
(Adding Dave Howells, his name is on iget-stop-isofs-from-using-read_inode.patch) On Tue, 18 Dec 2007 10:37:32 +0800, Dave Young said: I don't mind it failing the mount, but the oops seems excessive. I suspect that *somewhere* in that stack trace, we're wanting something like a if (!foo_ptr) return -EIO; but I admit not being competent enough to decide where that should be. Hi, Could you please try the below patch: Signed-off-by: Dave Young [EMAIL PROTECTED] --- fs/isofs/inode.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) With that patch applied, I took the ISO image (which I ended up reading on another machine and copying over the net to get a complete usable image), and dd'ed just the first 150M into another file, and tried to loopback mount it. And I got: # mount -o ro,loop /path/to/cd.partial.image /mnt/loop mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so And my dmesg says: [ 33.622073] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 33.622125] attempt to access beyond end of device [ 33.622129] loop0: rw=0, want=1284500, limit=30 [ 33.622133] ISOFS: unable to read i-node block Here is where we would oops before - now it errors out more reasonably: [ 33.622140] ISOFS: changing to secondary root [ 33.622148] attempt to access beyond end of device [ 33.622151] loop0: rw=0, want=1284508, limit=30 [ 33.622155] ISOFS: unable to read i-node block [ 33.622159] isofs_fill_super: get root inode failed So that fixes *this* bug. I looked in the -rc5-mm1 broken-out/, saw the vast multitudes of 'iget-stop-foofs-from-using' patches, and decided that somebody else will probably have to audit them for sanity. In the iget-* series, there's some 184 'return ERR_PTR(-EFOO);' for some FOO, and 3 other uses: % grep ERR_PTR iget* | grep -v return iget-stop-isofs-from-using-read_inode.patch:+ inode = ERR_PTR(ret); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:+parent = ERR_PTR(-ENOMEM); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:-parent = ERR_PTR(-EACCES); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:-parent = ERR_PTR(-ENOMEM); isofs is the only place we don't return a constant 'ERR_PTR(-EFOO)', but cast somebody else's return value. I wish I understood what that tells us. ;) pgppwUchT0vXx.pgp Description: PGP signature
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
Andrew Morton [EMAIL PROTECTED] wrote:
- inode = ERR_PTR(ret);
+ return NULL;
} else {
unlock_new_inode(inode);
}
Yup.
Nope. The correct fix is to make the various callers use IS_ERR() to check
the result of this function rather than checking for a NULL return.
David, this is concerning. More such error-path bugs in that code will take
years and years to get found and fixed.
Yes, I know. I've looked over the patches several times, however I know there
may be bugs in there because I may have made assumptions about what I've
written that cause me to overlook things. It's a danger of checking your own
code:-(
The best way to eliminate them is a line-by-line re-review of the patchset.
And ideally by someone other than me. Some of them have been reviewed by
other people, but I'm not sure that all have.
However, I've just had another look through. ISOFS appears to be the only one
in which I'd missed updating the callers. I've sent you a patch for it.
Note that I expressed reservations about three filesystems in the cover note
(FAT, HPPFS and HOSTFS), but nothing seems to have come of it.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Dec 19, 2007 9:22 AM, David Howells [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
- inode = ERR_PTR(ret);
+ return NULL;
} else {
unlock_new_inode(inode);
}
Yup.
Nope. The correct fix is to make the various callers use IS_ERR() to check
the result of this function rather than checking for a NULL return.
David, this is concerning. More such error-path bugs in that code will take
years and years to get found and fixed.
Yes, I know. I've looked over the patches several times, however I know there
may be bugs in there because I may have made assumptions about what I've
written that cause me to overlook things. It's a danger of checking your own
code:-(
The best way to eliminate them is a line-by-line re-review of the patchset.
And ideally by someone other than me. Some of them have been reviewed by
other people, but I'm not sure that all have.
However, I've just had another look through. ISOFS appears to be the only one
in which I'd missed updating the callers. I've sent you a patch for it.
Note that I expressed reservations about three filesystems in the cover note
(FAT, HPPFS and HOSTFS), but nothing seems to have come of it.
Hi,
The oops is at iput, I use 'return NULL ' is because I don't want to
change the the behaviour of iput in fs/inode.c.
Regards
dave
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Wed, 19 Dec 2007 01:22:21 + David Howells [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
- inode = ERR_PTR(ret);
+ return NULL;
} else {
unlock_new_inode(inode);
}
Yup.
Nope. The correct fix is to make the various callers use IS_ERR() to check
the result of this function rather than checking for a NULL return.
David, this is concerning. More such error-path bugs in that code will take
years and years to get found and fixed.
Yes, I know. I've looked over the patches several times, however I know there
may be bugs in there because I may have made assumptions about what I've
written that cause me to overlook things. It's a danger of checking your own
code:-(
The best way to eliminate them is a line-by-line re-review of the patchset.
And ideally by someone other than me. Some of them have been reviewed by
other people, but I'm not sure that all have.
However, I've just had another look through. ISOFS appears to be the only one
in which I'd missed updating the callers. I've sent you a patch for it.
Note that I expressed reservations about three filesystems in the cover note
(FAT, HPPFS and HOSTFS), but nothing seems to have come of it.
Nobody seems to look after hppfs. I'll resend the fat and hostfs patches to
maintainers for a review, please.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Tue, Dec 18, 2007 at 06:04:58PM -0800, Andrew Morton wrote: Nobody seems to look after hppfs. I'll resend the fat and hostfs patches to maintainers for a review, please. It's mine - I'll take a look at it. Jeff -- Work email - jdike at linux dot intel dot com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Tue, 18 Dec 2007 10:37:32 +0800 Dave Young <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
> > On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
> >
> > (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS
> > doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
> > actually does that code?)
> >
> > > > I try it again, and it reports it died at the same exact place, but in
> > > > about
> > > > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I
> > > > didn't
> > > > think that blocks read from /dev/cdrom would get cached, but OK.
> > >
> > > It'll remain cached if something is holding the device open.
> >
> > Does it need to be "device open", or are there other things as well? If the
> > drop_cache was hosed, that would result in the same symptoms, no?
> >
> > > Something's holding s_umount for writing I guess. Possibly busted error
> > > handling somewhere totally different.
> >
> > Aha - found what was holding it - an attempt to loopback mount the truncated
> > file (before I realized it was truncated) had failed - I had gotten a
> > 'Killed'
> > back from the mount, but I didn't realize it had pulled an actual oops:
> >
> > Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access
> > beyond end of device
> > Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0,
> > want=1284500, limit=314240
> > Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read
> > i-node block
> > Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle
> > kernel NULL pointer dereference at 010b RIP:
> > Dec 17 15:54:33 turing-police kernel: [14503.402440] []
> > iput+0x11/0x80
> > ...
> > Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace:
> > Dec 17 15:54:33 turing-police kernel: [14503.403026] []
> > isofs_fill_super+0x7e9/0xa6b
> > Dec 17 15:54:33 turing-police kernel: [14503.403045] []
> > __down_write_nested+0x3d/0xa1
> > Dec 17 15:54:33 turing-police kernel: [14503.403061] []
> > __down_write+0xb/0xd
> > Dec 17 15:54:33 turing-police kernel: [14503.403076] []
> > sget+0x397/0x3a9
> > Dec 17 15:54:33 turing-police kernel: [14503.403090] []
> > set_bdev_super+0x0/0x14
> > Dec 17 15:54:33 turing-police kernel: [14503.403106] []
> > get_sb_bdev+0x109/0x157
> > Dec 17 15:54:33 turing-police kernel: [14503.403120] []
> > isofs_fill_super+0x0/0xa6b
> > Dec 17 15:54:33 turing-police kernel: [14503.403138] []
> > isofs_get_sb+0x13/0x15
> > Dec 17 15:54:33 turing-police kernel: [14503.403151] []
> > vfs_kern_mount+0x90/0x11a
> > Dec 17 15:54:33 turing-police kernel: [14503.403167] []
> > do_kern_mount+0x47/0xe3
> > Dec 17 15:54:33 turing-police kernel: [14503.403183] []
> > do_mount+0x717/0x78a
> > Dec 17 15:54:33 turing-police kernel: [14503.403199] []
> > _read_lock_irq+0x9/0xb
> > Dec 17 15:54:33 turing-police kernel: [14503.403212] []
> > find_lock_page+0x8c/0x97
> > Dec 17 15:54:33 turing-police kernel: [14503.403227] []
> > filemap_fault+0x1fa/0x3c6
> > Dec 17 15:54:33 turing-police kernel: [14503.403241] []
> > unlock_page+0x2d/0x31
> > Dec 17 15:54:33 turing-police kernel: [14503.403254] []
> > __do_fault+0x38d/0x3c3
> > Dec 17 15:54:33 turing-police kernel: [14503.403274] []
> > handle_mm_fault+0x36d/0x6e9
> > Dec 17 15:54:33 turing-police kernel: [14503.403293] []
> > __alloc_pages+0x68/0x2f6
> > Dec 17 15:54:33 turing-police kernel: [14503.403314] []
> > sys_mount+0x89/0xcb
> > Dec 17 15:54:33 turing-police kernel: [14503.403328] []
> > syscall_trace_enter+0x97/0x9b
> > Dec 17 15:54:33 turing-police kernel: [14503.403344] []
> > tracesys+0xdc/0xe1
> > Dec 17 15:54:33 turing-police kernel: [14503.403359]
> > Dec 17 15:54:33 turing-police kernel: [14503.403366]
> > Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01
> > 00 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75
> >
> > I don't mind it failing the mount, but the oops seems excessive. I suspect
> > that *somewhere* in that stack trace, we're wanting something like a
> >
> > if (!foo_ptr)
> > return -EIO;
> >
> > but I admit not being competent enough to decide where that should be.
> >
>
> Hi,
> Could you please try the below patch:
>
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
>
> ---
> fs/isofs/inode.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -upr linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
> --- linux/fs/isofs/inode.c2007-12-18 10:31:12.0 +0800
> +++ linux.new/fs/isofs/inode.c2007-12-18 10:31:56.0 +0800
> @@ -1414,7 +1414,7 @@ struct inode *isofs_iget(struct super_bl
> ret = isofs_read_inode(inode);
> if (ret < 0) {
> iget_failed(inode);
> - inode = ERR_PTR(ret);
> + return NULL;
> } else {
>
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
> On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
>
> (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS
> doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
> actually does that code?)
>
> > > I try it again, and it reports it died at the same exact place, but in
> > > about
> > > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I
> > > didn't
> > > think that blocks read from /dev/cdrom would get cached, but OK.
> >
> > It'll remain cached if something is holding the device open.
>
> Does it need to be "device open", or are there other things as well? If the
> drop_cache was hosed, that would result in the same symptoms, no?
>
> > Something's holding s_umount for writing I guess. Possibly busted error
> > handling somewhere totally different.
>
> Aha - found what was holding it - an attempt to loopback mount the truncated
> file (before I realized it was truncated) had failed - I had gotten a 'Killed'
> back from the mount, but I didn't realize it had pulled an actual oops:
>
> Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access beyond
> end of device
> Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0,
> want=1284500, limit=314240
> Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read
> i-node block
> Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle kernel
> NULL pointer dereference at 010b RIP:
> Dec 17 15:54:33 turing-police kernel: [14503.402440] []
> iput+0x11/0x80
> ...
> Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace:
> Dec 17 15:54:33 turing-police kernel: [14503.403026] []
> isofs_fill_super+0x7e9/0xa6b
> Dec 17 15:54:33 turing-police kernel: [14503.403045] []
> __down_write_nested+0x3d/0xa1
> Dec 17 15:54:33 turing-police kernel: [14503.403061] []
> __down_write+0xb/0xd
> Dec 17 15:54:33 turing-police kernel: [14503.403076] []
> sget+0x397/0x3a9
> Dec 17 15:54:33 turing-police kernel: [14503.403090] []
> set_bdev_super+0x0/0x14
> Dec 17 15:54:33 turing-police kernel: [14503.403106] []
> get_sb_bdev+0x109/0x157
> Dec 17 15:54:33 turing-police kernel: [14503.403120] []
> isofs_fill_super+0x0/0xa6b
> Dec 17 15:54:33 turing-police kernel: [14503.403138] []
> isofs_get_sb+0x13/0x15
> Dec 17 15:54:33 turing-police kernel: [14503.403151] []
> vfs_kern_mount+0x90/0x11a
> Dec 17 15:54:33 turing-police kernel: [14503.403167] []
> do_kern_mount+0x47/0xe3
> Dec 17 15:54:33 turing-police kernel: [14503.403183] []
> do_mount+0x717/0x78a
> Dec 17 15:54:33 turing-police kernel: [14503.403199] []
> _read_lock_irq+0x9/0xb
> Dec 17 15:54:33 turing-police kernel: [14503.403212] []
> find_lock_page+0x8c/0x97
> Dec 17 15:54:33 turing-police kernel: [14503.403227] []
> filemap_fault+0x1fa/0x3c6
> Dec 17 15:54:33 turing-police kernel: [14503.403241] []
> unlock_page+0x2d/0x31
> Dec 17 15:54:33 turing-police kernel: [14503.403254] []
> __do_fault+0x38d/0x3c3
> Dec 17 15:54:33 turing-police kernel: [14503.403274] []
> handle_mm_fault+0x36d/0x6e9
> Dec 17 15:54:33 turing-police kernel: [14503.403293] []
> __alloc_pages+0x68/0x2f6
> Dec 17 15:54:33 turing-police kernel: [14503.403314] []
> sys_mount+0x89/0xcb
> Dec 17 15:54:33 turing-police kernel: [14503.403328] []
> syscall_trace_enter+0x97/0x9b
> Dec 17 15:54:33 turing-police kernel: [14503.403344] []
> tracesys+0xdc/0xe1
> Dec 17 15:54:33 turing-police kernel: [14503.403359]
> Dec 17 15:54:33 turing-police kernel: [14503.403366]
> Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01 00
> 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75
>
> I don't mind it failing the mount, but the oops seems excessive. I suspect
> that *somewhere* in that stack trace, we're wanting something like a
>
> if (!foo_ptr)
> return -EIO;
>
> but I admit not being competent enough to decide where that should be.
>
Hi,
Could you please try the below patch:
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
fs/isofs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
--- linux/fs/isofs/inode.c 2007-12-18 10:31:12.0 +0800
+++ linux.new/fs/isofs/inode.c 2007-12-18 10:31:56.0 +0800
@@ -1414,7 +1414,7 @@ struct inode *isofs_iget(struct super_bl
ret = isofs_read_inode(inode);
if (ret < 0) {
iget_failed(inode);
- inode = ERR_PTR(ret);
+ return NULL;
} else {
unlock_new_inode(inode);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said: (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever actually does that code?) > > I try it again, and it reports it died at the same exact place, but in about > > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't > > think that blocks read from /dev/cdrom would get cached, but OK. > > It'll remain cached if something is holding the device open. Does it need to be "device open", or are there other things as well? If the drop_cache was hosed, that would result in the same symptoms, no? > Something's holding s_umount for writing I guess. Possibly busted error > handling somewhere totally different. Aha - found what was holding it - an attempt to loopback mount the truncated file (before I realized it was truncated) had failed - I had gotten a 'Killed' back from the mount, but I didn't realize it had pulled an actual oops: Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access beyond end of device Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0, want=1284500, limit=314240 Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read i-node block Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle kernel NULL pointer dereference at 010b RIP: Dec 17 15:54:33 turing-police kernel: [14503.402440] [] iput+0x11/0x80 ... Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace: Dec 17 15:54:33 turing-police kernel: [14503.403026] [] isofs_fill_super+0x7e9/0xa6b Dec 17 15:54:33 turing-police kernel: [14503.403045] [] __down_write_nested+0x3d/0xa1 Dec 17 15:54:33 turing-police kernel: [14503.403061] [] __down_write+0xb/0xd Dec 17 15:54:33 turing-police kernel: [14503.403076] [] sget+0x397/0x3a9 Dec 17 15:54:33 turing-police kernel: [14503.403090] [] set_bdev_super+0x0/0x14 Dec 17 15:54:33 turing-police kernel: [14503.403106] [] get_sb_bdev+0x109/0x157 Dec 17 15:54:33 turing-police kernel: [14503.403120] [] isofs_fill_super+0x0/0xa6b Dec 17 15:54:33 turing-police kernel: [14503.403138] [] isofs_get_sb+0x13/0x15 Dec 17 15:54:33 turing-police kernel: [14503.403151] [] vfs_kern_mount+0x90/0x11a Dec 17 15:54:33 turing-police kernel: [14503.403167] [] do_kern_mount+0x47/0xe3 Dec 17 15:54:33 turing-police kernel: [14503.403183] [] do_mount+0x717/0x78a Dec 17 15:54:33 turing-police kernel: [14503.403199] [] _read_lock_irq+0x9/0xb Dec 17 15:54:33 turing-police kernel: [14503.403212] [] find_lock_page+0x8c/0x97 Dec 17 15:54:33 turing-police kernel: [14503.403227] [] filemap_fault+0x1fa/0x3c6 Dec 17 15:54:33 turing-police kernel: [14503.403241] [] unlock_page+0x2d/0x31 Dec 17 15:54:33 turing-police kernel: [14503.403254] [] __do_fault+0x38d/0x3c3 Dec 17 15:54:33 turing-police kernel: [14503.403274] [] handle_mm_fault+0x36d/0x6e9 Dec 17 15:54:33 turing-police kernel: [14503.403293] [] __alloc_pages+0x68/0x2f6 Dec 17 15:54:33 turing-police kernel: [14503.403314] [] sys_mount+0x89/0xcb Dec 17 15:54:33 turing-police kernel: [14503.403328] [] syscall_trace_enter+0x97/0x9b Dec 17 15:54:33 turing-police kernel: [14503.403344] [] tracesys+0xdc/0xe1 Dec 17 15:54:33 turing-police kernel: [14503.403359] Dec 17 15:54:33 turing-police kernel: [14503.403366] Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01 00 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75 I don't mind it failing the mount, but the oops seems excessive. I suspect that *somewhere* in that stack trace, we're wanting something like a if (!foo_ptr) return -EIO; but I admit not being competent enough to decide where that should be. pgp96V9uaXsyW.pgp Description: PGP signature
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, 17 Dec 2007 17:44:11 -0500 [EMAIL PROTECTED] wrote: > On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ > > OK, so I'm trying to 'dd' a CD and the drive on the laptop is having issues > reading the disk. > > I try it once, and get an I/O error about 117M in - dd reports 1.7M/sec. > > I try it again, and it reports it died at the same exact place, but in about > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't > think that blocks read from /dev/cdrom would get cached, but OK. It'll remain cached if something is holding the device open. > So I try > the obviously stupid thing: > > # echo 1 >| /proc/sys/vm/drop_caches > > Alas, that hangs gloriously - 'echo t > /proc/sysrq-trigger' tells me: > > Dec 17 17:30:02 turing-police kernel: [20235.823201] bash D > 0001 5288 15123 15085 > Dec 17 17:30:02 turing-police kernel: [20235.823206] 81007ba7de28 > 0086 > Dec 17 17:30:02 turing-police kernel: [20235.823210] 81007bbd9000 > 81007d70e000 81007bbd9248 0001019e3e48 > Dec 17 17:30:02 turing-police kernel: [20235.823214] e2f36028 > e200012b9978 e2eece48 e20001164188 > Dec 17 17:30:02 turing-police kernel: [20235.823218] Call Trace: > Dec 17 17:30:02 turing-police kernel: [20235.823224] [] > __down_read+0x87/0xa1 > Dec 17 17:30:02 turing-police kernel: [20235.823229] [] > down_read+0x9/0xe > Dec 17 17:30:02 turing-police kernel: [20235.823232] [] > drop_pagecache+0x3a/0x8c > Dec 17 17:30:02 turing-police kernel: [20235.823235] [] > drop_caches_sysctl_handler+0x22/0x38 > Dec 17 17:30:02 turing-police kernel: [20235.823239] [] > proc_sys_write+0x7e/0xa6 > Dec 17 17:30:02 turing-police kernel: [20235.823244] [] > vfs_write+0xc7/0x170 > Dec 17 17:30:02 turing-police kernel: [20235.823248] [] > sys_write+0x47/0x70 > Dec 17 17:30:02 turing-police kernel: [20235.823251] [] > tracesys+0xdc/0xe1 > Something's holding s_umount for writing I guess. Possibly busted error handling somewhere totally different. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ OK, so I'm trying to 'dd' a CD and the drive on the laptop is having issues reading the disk. I try it once, and get an I/O error about 117M in - dd reports 1.7M/sec. I try it again, and it reports it died at the same exact place, but in about 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't think that blocks read from /dev/cdrom would get cached, but OK. So I try the obviously stupid thing: # echo 1 >| /proc/sys/vm/drop_caches Alas, that hangs gloriously - 'echo t > /proc/sysrq-trigger' tells me: Dec 17 17:30:02 turing-police kernel: [20235.823201] bash D 0001 5288 15123 15085 Dec 17 17:30:02 turing-police kernel: [20235.823206] 81007ba7de28 0086 Dec 17 17:30:02 turing-police kernel: [20235.823210] 81007bbd9000 81007d70e000 81007bbd9248 0001019e3e48 Dec 17 17:30:02 turing-police kernel: [20235.823214] e2f36028 e200012b9978 e2eece48 e20001164188 Dec 17 17:30:02 turing-police kernel: [20235.823218] Call Trace: Dec 17 17:30:02 turing-police kernel: [20235.823224] [] __down_read+0x87/0xa1 Dec 17 17:30:02 turing-police kernel: [20235.823229] [] down_read+0x9/0xe Dec 17 17:30:02 turing-police kernel: [20235.823232] [] drop_pagecache+0x3a/0x8c Dec 17 17:30:02 turing-police kernel: [20235.823235] [] drop_caches_sysctl_handler+0x22/0x38 Dec 17 17:30:02 turing-police kernel: [20235.823239] [] proc_sys_write+0x7e/0xa6 Dec 17 17:30:02 turing-police kernel: [20235.823244] [] vfs_write+0xc7/0x170 Dec 17 17:30:02 turing-police kernel: [20235.823248] [] sys_write+0x47/0x70 Dec 17 17:30:02 turing-police kernel: [20235.823251] [] tracesys+0xdc/0xe1 Yowza. And no, I don't dare to try to reproduce it until Thursday at the earliest, I need a mostly-stable machine the next 2 days. ;) pgpoRMiaaSA1G.pgp Description: PGP signature
2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ OK, so I'm trying to 'dd' a CD and the drive on the laptop is having issues reading the disk. I try it once, and get an I/O error about 117M in - dd reports 1.7M/sec. I try it again, and it reports it died at the same exact place, but in about 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't think that blocks read from /dev/cdrom would get cached, but OK. So I try the obviously stupid thing: # echo 1 | /proc/sys/vm/drop_caches Alas, that hangs gloriously - 'echo t /proc/sysrq-trigger' tells me: Dec 17 17:30:02 turing-police kernel: [20235.823201] bash D 0001 5288 15123 15085 Dec 17 17:30:02 turing-police kernel: [20235.823206] 81007ba7de28 0086 Dec 17 17:30:02 turing-police kernel: [20235.823210] 81007bbd9000 81007d70e000 81007bbd9248 0001019e3e48 Dec 17 17:30:02 turing-police kernel: [20235.823214] e2f36028 e200012b9978 e2eece48 e20001164188 Dec 17 17:30:02 turing-police kernel: [20235.823218] Call Trace: Dec 17 17:30:02 turing-police kernel: [20235.823224] [80523e20] __down_read+0x87/0xa1 Dec 17 17:30:02 turing-police kernel: [20235.823229] [8024bc13] down_read+0x9/0xe Dec 17 17:30:02 turing-police kernel: [20235.823232] [802abafe] drop_pagecache+0x3a/0x8c Dec 17 17:30:02 turing-police kernel: [20235.823235] [802abb72] drop_caches_sysctl_handler+0x22/0x38 Dec 17 17:30:02 turing-police kernel: [20235.823239] [802d2b70] proc_sys_write+0x7e/0xa6 Dec 17 17:30:02 turing-police kernel: [20235.823244] [8028e18c] vfs_write+0xc7/0x170 Dec 17 17:30:02 turing-police kernel: [20235.823248] [8028e772] sys_write+0x47/0x70 Dec 17 17:30:02 turing-police kernel: [20235.823251] [8020c34c] tracesys+0xdc/0xe1 Yowza. And no, I don't dare to try to reproduce it until Thursday at the earliest, I need a mostly-stable machine the next 2 days. ;) pgpoRMiaaSA1G.pgp Description: PGP signature
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, 17 Dec 2007 17:44:11 -0500 [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ OK, so I'm trying to 'dd' a CD and the drive on the laptop is having issues reading the disk. I try it once, and get an I/O error about 117M in - dd reports 1.7M/sec. I try it again, and it reports it died at the same exact place, but in about 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't think that blocks read from /dev/cdrom would get cached, but OK. It'll remain cached if something is holding the device open. So I try the obviously stupid thing: # echo 1 | /proc/sys/vm/drop_caches Alas, that hangs gloriously - 'echo t /proc/sysrq-trigger' tells me: Dec 17 17:30:02 turing-police kernel: [20235.823201] bash D 0001 5288 15123 15085 Dec 17 17:30:02 turing-police kernel: [20235.823206] 81007ba7de28 0086 Dec 17 17:30:02 turing-police kernel: [20235.823210] 81007bbd9000 81007d70e000 81007bbd9248 0001019e3e48 Dec 17 17:30:02 turing-police kernel: [20235.823214] e2f36028 e200012b9978 e2eece48 e20001164188 Dec 17 17:30:02 turing-police kernel: [20235.823218] Call Trace: Dec 17 17:30:02 turing-police kernel: [20235.823224] [80523e20] __down_read+0x87/0xa1 Dec 17 17:30:02 turing-police kernel: [20235.823229] [8024bc13] down_read+0x9/0xe Dec 17 17:30:02 turing-police kernel: [20235.823232] [802abafe] drop_pagecache+0x3a/0x8c Dec 17 17:30:02 turing-police kernel: [20235.823235] [802abb72] drop_caches_sysctl_handler+0x22/0x38 Dec 17 17:30:02 turing-police kernel: [20235.823239] [802d2b70] proc_sys_write+0x7e/0xa6 Dec 17 17:30:02 turing-police kernel: [20235.823244] [8028e18c] vfs_write+0xc7/0x170 Dec 17 17:30:02 turing-police kernel: [20235.823248] [8028e772] sys_write+0x47/0x70 Dec 17 17:30:02 turing-police kernel: [20235.823251] [8020c34c] tracesys+0xdc/0xe1 Something's holding s_umount for writing I guess. Possibly busted error handling somewhere totally different. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said: (Adding Al Viro to the list, he's listed as file systems and MAINTAINERS doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever actually does that code?) I try it again, and it reports it died at the same exact place, but in about 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't think that blocks read from /dev/cdrom would get cached, but OK. It'll remain cached if something is holding the device open. Does it need to be device open, or are there other things as well? If the drop_cache was hosed, that would result in the same symptoms, no? Something's holding s_umount for writing I guess. Possibly busted error handling somewhere totally different. Aha - found what was holding it - an attempt to loopback mount the truncated file (before I realized it was truncated) had failed - I had gotten a 'Killed' back from the mount, but I didn't realize it had pulled an actual oops: Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access beyond end of device Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0, want=1284500, limit=314240 Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read i-node block Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle kernel NULL pointer dereference at 010b RIP: Dec 17 15:54:33 turing-police kernel: [14503.402440] [802a096b] iput+0x11/0x80 ... Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace: Dec 17 15:54:33 turing-police kernel: [14503.403026] [802ff73e] isofs_fill_super+0x7e9/0xa6b Dec 17 15:54:33 turing-police kernel: [14503.403045] [80523d28] __down_write_nested+0x3d/0xa1 Dec 17 15:54:33 turing-police kernel: [14503.403061] [80523d97] __down_write+0xb/0xd Dec 17 15:54:33 turing-police kernel: [14503.403076] [8028fb63] sget+0x397/0x3a9 Dec 17 15:54:33 turing-police kernel: [14503.403090] [8028f204] set_bdev_super+0x0/0x14 Dec 17 15:54:33 turing-police kernel: [14503.403106] [80290301] get_sb_bdev+0x109/0x157 Dec 17 15:54:33 turing-police kernel: [14503.403120] [802fef55] isofs_fill_super+0x0/0xa6b Dec 17 15:54:33 turing-police kernel: [14503.403138] [802fe2e9] isofs_get_sb+0x13/0x15 Dec 17 15:54:33 turing-police kernel: [14503.403151] [80290075] vfs_kern_mount+0x90/0x11a Dec 17 15:54:33 turing-police kernel: [14503.403167] [8029015c] do_kern_mount+0x47/0xe3 Dec 17 15:54:33 turing-police kernel: [14503.403183] [802a5012] do_mount+0x717/0x78a Dec 17 15:54:33 turing-police kernel: [14503.403199] [805242fc] _read_lock_irq+0x9/0xb Dec 17 15:54:33 turing-police kernel: [14503.403212] [8026cce0] find_lock_page+0x8c/0x97 Dec 17 15:54:33 turing-police kernel: [14503.403227] [8026ecb6] filemap_fault+0x1fa/0x3c6 Dec 17 15:54:33 turing-police kernel: [14503.403241] [8026cb6b] unlock_page+0x2d/0x31 Dec 17 15:54:33 turing-police kernel: [14503.403254] [8027925c] __do_fault+0x38d/0x3c3 Dec 17 15:54:33 turing-police kernel: [14503.403274] [8027ab68] handle_mm_fault+0x36d/0x6e9 Dec 17 15:54:33 turing-police kernel: [14503.403293] [80271903] __alloc_pages+0x68/0x2f6 Dec 17 15:54:33 turing-police kernel: [14503.403314] [802a510e] sys_mount+0x89/0xcb Dec 17 15:54:33 turing-police kernel: [14503.403328] [80214f34] syscall_trace_enter+0x97/0x9b Dec 17 15:54:33 turing-police kernel: [14503.403344] [8020c34c] tracesys+0xdc/0xe1 Dec 17 15:54:33 turing-police kernel: [14503.403359] Dec 17 15:54:33 turing-police kernel: [14503.403366] Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01 00 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75 I don't mind it failing the mount, but the oops seems excessive. I suspect that *somewhere* in that stack trace, we're wanting something like a if (!foo_ptr) return -EIO; but I admit not being competent enough to decide where that should be. pgp96V9uaXsyW.pgp Description: PGP signature
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
(Adding Al Viro to the list, he's listed as file systems and MAINTAINERS
doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
actually does that code?)
I try it again, and it reports it died at the same exact place, but in
about
2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I
didn't
think that blocks read from /dev/cdrom would get cached, but OK.
It'll remain cached if something is holding the device open.
Does it need to be device open, or are there other things as well? If the
drop_cache was hosed, that would result in the same symptoms, no?
Something's holding s_umount for writing I guess. Possibly busted error
handling somewhere totally different.
Aha - found what was holding it - an attempt to loopback mount the truncated
file (before I realized it was truncated) had failed - I had gotten a 'Killed'
back from the mount, but I didn't realize it had pulled an actual oops:
Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access beyond
end of device
Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0,
want=1284500, limit=314240
Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read
i-node block
Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle kernel
NULL pointer dereference at 010b RIP:
Dec 17 15:54:33 turing-police kernel: [14503.402440] [802a096b]
iput+0x11/0x80
...
Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace:
Dec 17 15:54:33 turing-police kernel: [14503.403026] [802ff73e]
isofs_fill_super+0x7e9/0xa6b
Dec 17 15:54:33 turing-police kernel: [14503.403045] [80523d28]
__down_write_nested+0x3d/0xa1
Dec 17 15:54:33 turing-police kernel: [14503.403061] [80523d97]
__down_write+0xb/0xd
Dec 17 15:54:33 turing-police kernel: [14503.403076] [8028fb63]
sget+0x397/0x3a9
Dec 17 15:54:33 turing-police kernel: [14503.403090] [8028f204]
set_bdev_super+0x0/0x14
Dec 17 15:54:33 turing-police kernel: [14503.403106] [80290301]
get_sb_bdev+0x109/0x157
Dec 17 15:54:33 turing-police kernel: [14503.403120] [802fef55]
isofs_fill_super+0x0/0xa6b
Dec 17 15:54:33 turing-police kernel: [14503.403138] [802fe2e9]
isofs_get_sb+0x13/0x15
Dec 17 15:54:33 turing-police kernel: [14503.403151] [80290075]
vfs_kern_mount+0x90/0x11a
Dec 17 15:54:33 turing-police kernel: [14503.403167] [8029015c]
do_kern_mount+0x47/0xe3
Dec 17 15:54:33 turing-police kernel: [14503.403183] [802a5012]
do_mount+0x717/0x78a
Dec 17 15:54:33 turing-police kernel: [14503.403199] [805242fc]
_read_lock_irq+0x9/0xb
Dec 17 15:54:33 turing-police kernel: [14503.403212] [8026cce0]
find_lock_page+0x8c/0x97
Dec 17 15:54:33 turing-police kernel: [14503.403227] [8026ecb6]
filemap_fault+0x1fa/0x3c6
Dec 17 15:54:33 turing-police kernel: [14503.403241] [8026cb6b]
unlock_page+0x2d/0x31
Dec 17 15:54:33 turing-police kernel: [14503.403254] [8027925c]
__do_fault+0x38d/0x3c3
Dec 17 15:54:33 turing-police kernel: [14503.403274] [8027ab68]
handle_mm_fault+0x36d/0x6e9
Dec 17 15:54:33 turing-police kernel: [14503.403293] [80271903]
__alloc_pages+0x68/0x2f6
Dec 17 15:54:33 turing-police kernel: [14503.403314] [802a510e]
sys_mount+0x89/0xcb
Dec 17 15:54:33 turing-police kernel: [14503.403328] [80214f34]
syscall_trace_enter+0x97/0x9b
Dec 17 15:54:33 turing-police kernel: [14503.403344] [8020c34c]
tracesys+0xdc/0xe1
Dec 17 15:54:33 turing-police kernel: [14503.403359]
Dec 17 15:54:33 turing-police kernel: [14503.403366]
Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01 00
00 48 83 bf 38 02 00 00 40 48 8b 40 38 75
I don't mind it failing the mount, but the oops seems excessive. I suspect
that *somewhere* in that stack trace, we're wanting something like a
if (!foo_ptr)
return -EIO;
but I admit not being competent enough to decide where that should be.
Hi,
Could you please try the below patch:
Signed-off-by: Dave Young [EMAIL PROTECTED]
---
fs/isofs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
--- linux/fs/isofs/inode.c 2007-12-18 10:31:12.0 +0800
+++ linux.new/fs/isofs/inode.c 2007-12-18 10:31:56.0 +0800
@@ -1414,7 +1414,7 @@ struct inode *isofs_iget(struct super_bl
ret = isofs_read_inode(inode);
if (ret 0) {
iget_failed(inode);
- inode = ERR_PTR(ret);
+ return NULL;
} else {
unlock_new_inode(inode);
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Tue, 18 Dec 2007 10:37:32 +0800 Dave Young [EMAIL PROTECTED] wrote:
On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
(Adding Al Viro to the list, he's listed as file systems and MAINTAINERS
doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
actually does that code?)
I try it again, and it reports it died at the same exact place, but in
about
2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I
didn't
think that blocks read from /dev/cdrom would get cached, but OK.
It'll remain cached if something is holding the device open.
Does it need to be device open, or are there other things as well? If the
drop_cache was hosed, that would result in the same symptoms, no?
Something's holding s_umount for writing I guess. Possibly busted error
handling somewhere totally different.
Aha - found what was holding it - an attempt to loopback mount the truncated
file (before I realized it was truncated) had failed - I had gotten a
'Killed'
back from the mount, but I didn't realize it had pulled an actual oops:
Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access
beyond end of device
Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0,
want=1284500, limit=314240
Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read
i-node block
Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle
kernel NULL pointer dereference at 010b RIP:
Dec 17 15:54:33 turing-police kernel: [14503.402440] [802a096b]
iput+0x11/0x80
...
Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace:
Dec 17 15:54:33 turing-police kernel: [14503.403026] [802ff73e]
isofs_fill_super+0x7e9/0xa6b
Dec 17 15:54:33 turing-police kernel: [14503.403045] [80523d28]
__down_write_nested+0x3d/0xa1
Dec 17 15:54:33 turing-police kernel: [14503.403061] [80523d97]
__down_write+0xb/0xd
Dec 17 15:54:33 turing-police kernel: [14503.403076] [8028fb63]
sget+0x397/0x3a9
Dec 17 15:54:33 turing-police kernel: [14503.403090] [8028f204]
set_bdev_super+0x0/0x14
Dec 17 15:54:33 turing-police kernel: [14503.403106] [80290301]
get_sb_bdev+0x109/0x157
Dec 17 15:54:33 turing-police kernel: [14503.403120] [802fef55]
isofs_fill_super+0x0/0xa6b
Dec 17 15:54:33 turing-police kernel: [14503.403138] [802fe2e9]
isofs_get_sb+0x13/0x15
Dec 17 15:54:33 turing-police kernel: [14503.403151] [80290075]
vfs_kern_mount+0x90/0x11a
Dec 17 15:54:33 turing-police kernel: [14503.403167] [8029015c]
do_kern_mount+0x47/0xe3
Dec 17 15:54:33 turing-police kernel: [14503.403183] [802a5012]
do_mount+0x717/0x78a
Dec 17 15:54:33 turing-police kernel: [14503.403199] [805242fc]
_read_lock_irq+0x9/0xb
Dec 17 15:54:33 turing-police kernel: [14503.403212] [8026cce0]
find_lock_page+0x8c/0x97
Dec 17 15:54:33 turing-police kernel: [14503.403227] [8026ecb6]
filemap_fault+0x1fa/0x3c6
Dec 17 15:54:33 turing-police kernel: [14503.403241] [8026cb6b]
unlock_page+0x2d/0x31
Dec 17 15:54:33 turing-police kernel: [14503.403254] [8027925c]
__do_fault+0x38d/0x3c3
Dec 17 15:54:33 turing-police kernel: [14503.403274] [8027ab68]
handle_mm_fault+0x36d/0x6e9
Dec 17 15:54:33 turing-police kernel: [14503.403293] [80271903]
__alloc_pages+0x68/0x2f6
Dec 17 15:54:33 turing-police kernel: [14503.403314] [802a510e]
sys_mount+0x89/0xcb
Dec 17 15:54:33 turing-police kernel: [14503.403328] [80214f34]
syscall_trace_enter+0x97/0x9b
Dec 17 15:54:33 turing-police kernel: [14503.403344] [8020c34c]
tracesys+0xdc/0xe1
Dec 17 15:54:33 turing-police kernel: [14503.403359]
Dec 17 15:54:33 turing-police kernel: [14503.403366]
Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01
00 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75
I don't mind it failing the mount, but the oops seems excessive. I suspect
that *somewhere* in that stack trace, we're wanting something like a
if (!foo_ptr)
return -EIO;
but I admit not being competent enough to decide where that should be.
Hi,
Could you please try the below patch:
Signed-off-by: Dave Young [EMAIL PROTECTED]
---
fs/isofs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
--- linux/fs/isofs/inode.c2007-12-18 10:31:12.0 +0800
+++ linux.new/fs/isofs/inode.c2007-12-18 10:31:56.0 +0800
@@ -1414,7 +1414,7 @@ struct inode *isofs_iget(struct super_bl
ret = isofs_read_inode(inode);
if (ret 0) {
