Skip to contentSkip to conversation

problem with Andrew's patch ext3

DISCUSSION Octave 3 participants 6 messages Dec 15, 2002

lore
Share & tools
lore

Octave

author
#0 lore raw

Hello Andrew,

I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
and I have a big problem with:
once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs. I tested it on 50-60 servers and it is the same problem. I tested kernel 2.4.20 without your patch: no problem.

# uname -a 
Linux XXXXXX 2.4.20 #1 ven déc 13 17:21:23 CET 2002 i686 unknown
# /sbin/reboot

Broadcast message from root (pts/0) Sun Dec 15 14:26:03 2002...

The system is going down for reboot NOW !! Segmentation fault
#
# dmRead from remote host XXXXXXXX: Connection reset by peer

It is crashed.

no logs :/

Regards
Octave

#1 lore raw

Hi,

@@ -454,6 +456,7 @@ static struct super_operations ext3_sops
delete_inode: ext3_delete_inode, /* BKL not held. We take it */
put_super: ext3_put_super, /* BKL held */
write_super: ext3_write_super, /* BKL held */
+ sync_fs: ext3_sync_fs,
write_super_lockfs: ext3_write_super_lockfs, /* BKL not held. Take it
*/
unlockfs: ext3_unlockfs, /* BKL not held. We take it */
statfs: ext3_statfs, /* BKL held */
@@ -1577,24 +1580,22 @@ int ext3_force_commit(struct super_block
* This implicitly triggers the writebehind on sync().
*/

Someone can explain to me how he can put a sync_fs label into a super_operation structure ?
The segfault is normal.

==> Linux/Documentation/filesystems/vfs.txt
177 struct super_operations {

178         void (*read_inode) (struct inode *);
179         void (*write_inode) (struct inode *, int);
180         void (*put_inode) (struct inode *);
181         void (*delete_inode) (struct inode *);
182         int (*notify_change) (struct dentry *, struct iattr *);
183         void (*put_super) (struct super_block *);
184         void (*write_super) (struct super_block *);
185         int (*statfs) (struct super_block *, struct statfs *, int);
186         int (*remount_fs) (struct super_block *, int *, char *);
187         void (*clear_inode) (struct inode *);

188 };

Well,

==> Linux/Documentation/filesystems/vfs.txt
327 struct file_operations {

328         loff_t (*llseek) (struct file *, loff_t, int);
329         ssize_t (*read) (struct file *, char *, size_t, loff_t *);
330         ssize_t (*write) (struct file *, const char *, size_t, loff_t

*);
331 int (*readdir) (struct file *, void *, filldir_t);
332 unsigned int (*poll) (struct file *, struct poll_table_struct
*);
333 int (*ioctl) (struct inode *, struct file *, unsigned int,
unsigned long);

334         int (*mmap) (struct file *, struct vm_area_struct *);
335         int (*open) (struct inode *, struct file *);
336         int (*release) (struct inode *, struct file *);
337         int (*fsync) (struct file *, struct dentry *);
338         int (*fasync) (struct file *, int);
339         int (*check_media_change) (kdev_t dev);
340         int (*revalidate) (kdev_t dev);
341         int (*lock) (struct file *, int, struct file_lock *);

342 };

You can only use a sync function into the file_operation structure. Well the patch can't work.

Octave, anyway you don't need this patch :P
Everything is already implemented.

Or perhaps i'v lost something ?!

Regards,
Michael

============================================================================
===
===============================ORIGINAL MESSAGE===============================
============================================================================
===
From: "Octave" <[email protected]>
To: "Andrew Morton" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Sunday, December 15, 2002 3:40 PM
Subject: problem with Andrew's patch ext3

Quoted 3 lines

Hello Andrew,

I patched 2.4.20 with your patch found out on

http://lwn.net/Articles/17447/

Quoted 31 lines

and I have a big problem with:
once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs. I tested it on 50-60 servers and it is the same problem. I tested kernel 2.4.20 without your patch: no problem.

# uname -a
Linux XXXXXX 2.4.20 #1 ven déc 13 17:21:23 CET 2002 i686 unknown
# /sbin/reboot

Broadcast message from root (pts/0) Sun Dec 15 14:26:03 2002...

The system is going down for reboot NOW !! Segmentation fault
#
# dmRead from remote host XXXXXXXX: Connection reset by peer

It is crashed.

no logs :/

Regards
Octave

-
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 lore raw
In reply to Octave
Quoted 7 lines · Octave

Hello Andrew,

I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
and I have a big problem with:
once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs.

It works OK here. Could you please check that the kernel was fully rebuilt? Do a `make clean'? If the kernel was not fully rebuilt then things will go wrong because a structure size was changed.

There is a locking error in that patch, and it needs revision. But that wouldn't explain this crash.

And there is an unrelated use-after-free bug which could cause problems if the fs runs out of space or inodes.

I'll get some fixes out later today. It hasn't been a good week.

author
#3 lore raw
Quoted 4 lines · Andrew Morton
Quoted 3 lines · Octave

Hello Andrew,

Quoted 8 lines
Quoted 4 lines

I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
and I have a big problem with:
once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs.

It works OK here. Could you please check that the kernel was fully rebuilt? Do a `make clean'? If the kernel was not fully rebuilt then things will go wrong because a structure size was changed.

yes, since I took a new tar.gz
made dep && make clean && make bzImage
I did it 5 times (for differents servers).

Octave

Quoted 8 lines

There is a locking error in that patch, and it needs revision. But that wouldn't explain this crash.

And there is an unrelated use-after-free bug which could cause problems if the fs runs out of space or inodes.

I'll get some fixes out later today. It hasn't been a good week.

#4 lore raw
Quoted 11 lines · Octave
Quoted 9 lines · Andrew Morton
Quoted 7 lines · Octave

Hello Andrew,

I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
and I have a big problem with:
once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs.

Quoted 8 lines
Quoted 3 lines

It works OK here. Could you please check that the kernel was fully rebuilt? Do a `make clean'? If the kernel was not fully rebuilt then things will go wrong because a structure size was changed.

yes, since I took a new tar.gz
made dep && make clean && make bzImage
I did it 5 times (for differents servers).

So is any additional information available? What was on the console? If it was a kernel crash, a ksymoops trace would be valuable.

The patch is at
http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/sync_fs.patch
could you ensure that it was applied successfully?