Hi,
Here are yet more results from the MC project. This checker looks for
inconsistent usage of interrupt functions. For example, it notices when
interrupts can be either on or off when a function exits. It tracks
cli(), sti(), save_flags() and so forth. We've hand-inspected the results
to en
Hi,
This checker warns when the pointer returned by a "plausibly" failing
routine is not checked before being used.
It automatically builds up the list of failing routines by examining
all callsites. If a function's returned pointer is checked at more
than one callsite, the checker ensures it i
> Your reporting is a little misleading here.
Thanks for verifying these bugs ;)
The interrupt checker checks for inconsistent interrupt states. For
example, if a function has one exit point with interrupt disabled, and
another exit point with interrupt enabled, the checker will report an
error
Hi, we modified the block checker and run it again on linux 2.4.1. (The
block checker flags an error when blocking functions are called with
either interrupts disabled or a spin lock held. )
It gave us 4 warnings in kernel/module.c. Because we are unaware of the
contexts where these functions are
On Fri, 23 Mar 2001, Keith Owens wrote:
> On Fri, 23 Mar 2001 02:41:40 -0800 (PST),
> Junfeng Yang <[EMAIL PROTECTED]> wrote:
> >Hi, we modified the block checker and run it again on linux 2.4.1. (The
> >block checker flags an error when blocking functions are called w
On Fri, 23 Mar 2001, Alan Cox wrote:
> > Hi, we modified the block checker and run it again on linux 2.4.1. (The
> > block checker flags an error when blocking functions are called with
> > either interrupts disabled or a spin lock held. )
>
> lock_kernel() isnt a spinlock as such.
Thanks a lot.
Hi,
I have a question about *_do_scsi(Scsi_Request *SRpnt, ...). If *SRpnt
is not NULL, *_do_scsi will not return NULL. I'm not quite sure about the
precondition in the following three 'errors' flaged by the NULL checker.
In these cases, can
*_do_scsi return NULL?
Another question is that
On Thu, 24 May 2001, Willem Riede wrote:
> Dawson Engler wrote:
> >
> > Hi All,
> >
> > Enclosed are 103 potential errors where code gets a pointer from a
> > possibly-failing routine (kmalloc, etc) and dereferences it without
> >
> > [BUG] osst_do_scsi will never return NULL if argument SRpnt is
> Interesting.
>
> $ /devel/linux/works/fatfs/fatfstools/dosfstools-2.10/dosfsck/dosfsck -a
> bug10/crash.img
> dosfsck 2.10, 22 Sep 2003, FAT32, LFN
> /0006
> Directory does not have any cluster ("." and "..").
> Dropping it.
> Reclaimed 3 unused clusters (6144 bytes) in 3 chains.
> Performi
> vfat and msdos doesn't support the link(), and the truncate() which
> extends size is not supported yet.
>
> This test seems to calling abort(0) by CHECK(ret)...
I updated the test case (basically just set CHECk to be a NOP). Can you
please download and re-run the test case? After reboot, run
> This is a known problem. Turn off the (default - grrr) subtree checking
> export option on the server, and it will all work properly. The subtree
> checking option violates the NFS standards for filehandle generation in
> so many ways, that it isn't even funny.
Thanks Trond. no_subtree_check fi
Hi,
FiSC found that at link operation and unlink operation on a NFS partion on
top of JFS are not sync'ed. These warnings show up in JFS but not in
ext2, ext3, so I suspect it's a potential JFS problem.
cat /etc/exports shows:
/mnt/sbd0-export localhost(rw,sync,no_subtree_check)
/mnt/
Does anyone know how to set up mmap on FUSE (linux user-land file system)?
Or is it even possible to have mmap on FUSE?
Our file system checker can potentially check a lot more things if we can
have mmap working on a FUSE file system. Your help on this are well
appreciated!
-Junfeng
-
To unsub
Forget to mention, we are checking linux 2.6. It appears to us that mmap
doesnt' work for FUSE in linux 2.6.
-Junfeng
On Sat, 12 Mar 2005, Junfeng Yang wrote:
>
> Does anyone know how to set up mmap on FUSE (linux user-land file system)?
> Or is it even possible to have mmap on
Hi,
We're working on a file system checker and have a question regarding what
sys_sync actually does. It appears to us that sys_sync should sync both
data and metadata, and wait until both data and metadata hit the disk
before it returns. Is this true for all the file systems (especially
ext2)
Hi,
I'm working on a linux file system checker right now. Can anyone
recommend a good kernel debugger for 2.6? I googled a bit before I post
to this mailing. It looks like kgdb and kdg are two choices. Which one
is better? Appears to me kgdb requires two machines.
Thanks,
-Junfeng
-
To uns
Hi,
I tried to read from a regular ext3 file opened as O_DIRECT, but got the
"Invalid argument" error. Running the same test program on a block device
succeeded.
uname -a shows
Linux *** 2.4.27-2-686-smp #1 SMP Thu Jan 20 11:02:39 JST 2005 i686
GNU/Linux
My test case is
#include
#include
Hi,
FiSC (our file system checker) emits several warnings on ext2, jfs and
reiserfs, complaining that diretories or files are lost while FiSC
believes they should already be persistent on disk. (ext3 behaves
correctly.)
All warnings boil down to a single cause: when these file systems are
mount
> It may happen that FISC reads the disk before the write command even finished.
> With all the HD head movement optimization in the kernel (block layer,
> boiling down to TCQ/NCQ), this sounds possible.
FiSC "crashes" the kernel immediately after a file system operation
(creat, mkdir, write, etc)
On Thu, 3 Mar 2005, Junfeng Yang wrote:
>
> Hi,
>
> FiSC (our file system checker) emits several warnings on ext2, jfs and
> reiserfs, complaining that diretories or files are lost while FiSC
> believes they should already be persistent on disk. (ext3 behaves
> correctly.)
> That would be a bug. Please send the e2fsck output.
Here is the trace
1. file system is made with sbin/mkfs.ext2 -F -b 1024 /dev/hda9 60
and mounted with -o sync,dirsync
1. operations FiSC did:
creat(/mnt/sbd0/0001)
write(/mnt/sbd0/0001)
rename(/mnt/sbd0/0001, /mnt/sbd0/0002)
mkdir(/mnt/sb
> >From a quick parse, ext2 seems to be full of MS_SYNCHRONOUS holes, and
> there might be some O_SYNC ones there as well.
I should be able to easily add O_SYNC check to FiSC. Several questions:
1. Does O_SYNC apply to directory as well?
2. For the same file, if I open twice, once with O_SYNC and
Hi,
FiSC (our FS checker) issues a warning on ext2, complaining that crash
after fsync causes file system to corrupt. FS corrupts in two different
ways: 1. file contains illegal blocks (such as block # -2) 2. one block
owned by two different files.
I diagnosed the warning a little bit and it ap
FiSC can still get those warnings with hdparm -W 0, or with a simple
ramdisk that serves the disk requests whenever they are submitted.
Thanks,
-Junfeng
On Mon, 7 Mar 2005, Alan Cox wrote:
> The IDE layer default is still unfortunately broken and leaves write
> caching enabled. Turn it off with
> fsync on ext2 only really guarantees that the data has reached
> the disk, what the disk does it outside the realm of the fs.
> If the ide drive has write back caching enabled, the data just
> might only be in cache. If the power is removed right after fsync
> returns, the drive might not get a c
Thanks a lot Andreas. Your message clarifies everything.
> In ext3 this case is handled because the filesystem won't reallocate the
> metadata blocks freed from file A before they have been committed to disk.
> Also, the operations on file A are guaranteed to complete before or with
> operations
> I believe the warning should go away if you mount -o sync (but then
> the filesystem will perform very slowly :-).
>
I do agree with you, Andreas and other ppl on that this is expected
behavior on ext2, and ext3 should be chosen over ext2 when such
corruptions are under consideration.
However,
> the mouth.) It is *expected* behaviour, yes, and it is mitigated by
> two factors. (1) Metadata for ext2 is synced out every 5 seconds,
> while data is synced out every 60, so the max window for this race
> described above is 5 seconds, and in practice rarely shows up if you
> are not using fsy
Hi,
FiSC founds a potential error on JFS (Linux 2.6.11) where fsync doesn't
properly flushes out file data. Crash after this fsync causes data loss.
The test case can be found at http://fisc.stanford.edu/bug9/crash.c
To reproduce it, download and compile crash.c, and run it on a fresh jfs
parti
Hi,
We are from the Stanford Checker team and are working on a file system
checker called FiSC. We checked XFS and found that even when a XFS
partition is mounted -o sync, file system operations are still not sync'ed
correctly.
A simple test case would be something like this:
mkdir 0001
reboot
Hi,
We are from the Stanford Checker team and are currently developing a file
system checker call FiSC. FiSC mainly focuses on finding crash-recovery
errors. We applied it to FiSC and found a serious error where crash then
recovery cause the file system to contain loops.
To reproduce the warni
Hi,
This is yet another report from FiSC :) This time FiSC complains that
sync on msdos and vfat doesn't flush everything out. Crash after sync
still causes data loss.
Test cases and crashed disk images can be found at
http://fisc.stanford.edu/bug8(msdos)
http://fisc.stanford.edu/bug11 (
> Linus's current tree includes support for `mount -o sync' on the msdos and
> vfat filesystems.
Thanks Andrew. I can just do a bk clone from
http://linux.bkbits.net/linux-2.6 to get Linus's current tree, right?
The warning reported here doesn't need mount -o sync to trigger though.
A simple cra
Hi,
We checked NFS on top of ext3 using FiSC (our file system model checker)
and found a case where NFS stat cache can contain inconsistent entries.
Basically, to trigger this inconsistency, just do the following steps:
1. create a file A1, write a few bytes to it, so A1 is 4 words
2. create a h
Hi,
We developed a file system checker called FiSC and recently applied it to
hfsplus. It complains 3 things about hfsplus:
1. sync on hfsplus doesn't actually flush everything out. Immediate crash
after sync still causes data-loss (testcase:
http://fisc.stanford.edu/bug13/crash.c)
2. fsync
Hi,
I tried to use pktgen module from 2.6.* kernels and found out that I
couldn't receive any packets generated by pktgen. I did not even see a
"packet dropped by kernel" message. It turned out that function
setup_inject in net/core/pktgen.c doesn't setup the ethernet header field
correctly. Be
36 matches
Mail list logo
