Page 1 of 11 123 ... LastLast
Results 1 to 10 of 105

Thread: The Linux Kernel SABOTEURS.

  1. #1
    Join Date
    Sep 2006
    Posts
    353

    Default The Linux Kernel SABOTEURS.

    The Linux Kernel Saboteurs.

    From http://linuxhelp.150m.com/
    and http://linux.50webs.org

    Although the Linux kernel saboteurs (a number of so called Linux kernel "developers") have sabotaged many areas of Linux, I will concentrate on their efforts in sabotaging Reiser4.

    As some will have noticed, Reiser4 no longer works as it used to. The recent patches of Andrew Morton, and Riffard Laurent, cause corruption problems (when they work at all). Morton's patches, also reduced Reiser4's functionality, removing, for example, the cryptocompress plugin. Riffard's patches include the cryptocompress plugin, which seems to work, but the patch causes corruption for plain Reiser4.

    You see, the Reiser4 saboteurs arranged that plain Reiser4 will not work properly. However, they forgot to sabotage the more complex case of transparent compression, so we have the weird situation where the more complex case works fine, while the kernel "developers" "struggle" to get the simple case to work like it used to.

    The parts of Reiser4 they have not touched, still work, but where they have coded, Reiser4 no longer works.

    The fact that Reiser4 worked well, before Hans Reiser's arrest and imprisonment (on what appears to be trumped-up charges) and now doesn't, means that it should be easy to spot the sabotage.

    After digging around in the source code, the evidence of deliberate sabotage is very clear.

    I present some of the evidence (found by comparing Riffard's patch with older Namesys patches) below.

    Update: Namesys has released 2.6.20 and 2.6.21 kernel patches. This has enabled one to completely isolate the differences between Namesys' 2.6.20 patch and Riffard's. The diff file is very small and can be found here. The early sabotage is concentrated in this small file.

    One act of sabotage, is found in reiser4/page_cache.c:

    Code:
    int reiser4_page_io(struct page *page, jnode *node, int rw, gfp_t gfp)
    {
    	struct bio *bio;
    	int result;
    
    	assert("nikita-2094", page != NULL);
    	assert("nikita-2226", PageLocked(page));
    	assert("nikita-2634", node != NULL);
    	assert("nikita-2893", rw == READ || rw == WRITE);
    
    	if (rw) {
    		if (unlikely(page->mapping->host->i_sb->s_flags & MS_RDONLY)) {
    			unlock_page(page);
    			return 0;
    		}
    	}
    
    	bio = page_bio(page, node, rw, gfp);
    	if (!IS_ERR(bio)) {
    		if (rw == WRITE) {
    			SetPageWriteback(page); 
    	Changed to	set_page_writeback(page);
    			unlock_page(page);
    		}
    		reiser4_submit_bio(rw, bio);
    		result = 0;
    	} else {
    		unlock_page(page);
    		result = PTR_ERR(bio);
    	}
    
    	return result;
    }
    where SetPageWriteback has been changed to set_page_writeback.

    This change is hard to spot with SetPageWriteback and set_page_writeback, being very similar in name. This change is almost guaranteed to cause problems, as set_page_writeback is called without calling end_page_writeback(). According to Documentation/filesystems/Locking, this will leave the page itself marked clean but it will be tagged as dirty in the radix tree. This incoherency can lead to all sorts of hard-to-debug problems in the filesystem like having dirty inodes at umount and losing written data. Just as the saboteurs desire, and what we see happening.

    The definition of SetPageWriteback is found in linux-2.6.20/include/linux/page-flags.h,

    Code:
    #define SetPageWriteback(page)                                          \
            do {                                                            \
                    if (!test_and_set_bit(PG_writeback,                     \
                                    &(page)->flags))                        \
                            inc_zone_page_state(page, NR_WRITEBACK);        \
            } while (0)
    as is the definition of set_page_writeback,
    static inline void set_page_writeback(struct page *page)
    {
            test_set_page_writeback(page);
    }
    where test_set_page_writeback (from linux-2.6.20/mm/page-writeback.c) is:

    Code:
    int test_set_page_writeback(struct page *page)
    {
            struct address_space *mapping = page_mapping(page);
            int ret;
    
            if (mapping) {
                    unsigned long flags;
    
                    write_lock_irqsave(&mapping->tree_lock, flags);
                    ret = TestSetPageWriteback(page);
                    if (!ret)
                            radix_tree_tag_set(&mapping->page_tree,
                                                    page_index(page),
                                                    PAGECACHE_TAG_WRITEBACK);
                    if (!PageDirty(page))
                            radix_tree_tag_clear(&mapping->page_tree,
                                                    page_index(page),
                                                    PAGECACHE_TAG_DIRTY);
                    write_unlock_irqrestore(&mapping->tree_lock, flags);
            } else {
                    ret = TestSetPageWriteback(page);
            }
            return ret;
    
    }
    EXPORT_SYMBOL(test_set_page_writeback);
    From the above definitions, it is clear that swapping set_page_writeback for SetPageWriteback was not an accidental mistake (the code is completely different).

    The patch, move-page-writeback-acounting-out-of-macros.patch, is Andrew Morton's attempt to completely cover his tracks. He claims it is "inconsistent" and "awkward" to have the three page-writeback accounting macros in include/linux/page-flags.h (together with all the other page macros) and that it would be better somehow, if they were moved to mm/page-writeback.c. However, not a single one of these definitions is actually transfered to mm/page-writeback.c. Two of them have their definition split between the two named files and the third, SetPageWriteback, is "accidentally" lost. It just disappears.

    In this way, Andrew Morton completely eliminates all reference to SetPageWriteback in the (2.6.21) mm-kernel.

    The patch move-page-writeback-acounting-out-of-macros.patch is presented here:
    From: Andrew Morton

    Code:
    page-writeback accounting is presently performed in the page-flags macros.
    This is inconsistent and makes it awkward to implement per-backing_dev
    under-writeback page accounting.
    
    So move this accounting down to the callsite(s).
    
    Signed-off-by: Andrew Morton 
    ---
    
     include/linux/page-flags.h |   38 +++++++----------------------------
     mm/page-writeback.c        |    4 +++
     2 files changed, 12 insertions(+), 30 deletions(-)
    
    diff -puN include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros include/linux/page-flags.h
    --- a/include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros
    +++ a/include/linux/page-flags.h
    @@ -184,37 +184,15 @@ static inline void SetPageUptodate(struc
     #define __SetPagePrivate(page)  __set_bit(PG_private, &(page)->flags)
     #define __ClearPagePrivate(page) __clear_bit(PG_private, &(page)->flags)
     
    +/*
    + * Only test-and-set exist for PG_writeback.  The unconditional operators are
    + * risky: they bypass page accounting.
    + */
     #define PageWriteback(page)	test_bit(PG_writeback, &(page)->flags)
    -#define SetPageWriteback(page)						\
    -	do {								\
    -		if (!test_and_set_bit(PG_writeback,			\
    -				&(page)->flags))			\
    -			inc_zone_page_state(page, NR_WRITEBACK);	\
    -	} while (0)
    -#define TestSetPageWriteback(page)					\
    -	({								\
    -		int ret;						\
    -		ret = test_and_set_bit(PG_writeback,			\
    -					&(page)->flags);		\
    -		if (!ret)						\
    -			inc_zone_page_state(page, NR_WRITEBACK);	\
    -		ret;							\
    -	})
    -#define ClearPageWriteback(page)					\
    -	do {								\
    -		if (test_and_clear_bit(PG_writeback,			\
    -				&(page)->flags))			\
    -			dec_zone_page_state(page, NR_WRITEBACK);	\
    -	} while (0)
    -#define TestClearPageWriteback(page)					\
    -	({								\
    -		int ret;						\
    -		ret = test_and_clear_bit(PG_writeback,			\
    -				&(page)->flags);			\
    -		if (ret)						\
    -			dec_zone_page_state(page, NR_WRITEBACK);	\
    -		ret;							\
    -	})
    +#define TestSetPageWriteback(page) test_and_set_bit(PG_writeback,	\
    +							&(page)->flags)
    +#define TestClearPageWriteback(page) test_and_clear_bit(PG_writeback,	\
    +							&(page)->flags)
     
     #define PageBuddy(page)		test_bit(PG_buddy, &(page)->flags)
     #define __SetPageBuddy(page)	__set_bit(PG_buddy, &(page)->flags)
    diff -puN mm/page-writeback.c~move-page-writeback-acounting-out-of-macros mm/page-writeback.c
    --- a/mm/page-writeback.c~move-page-writeback-acounting-out-of-macros
    +++ a/mm/page-writeback.c
    @@ -987,6 +987,8 @@ int test_clear_page_writeback(struct pag
     	} else {
     		ret = TestClearPageWriteback(page);
     	}
    +	if (ret)
    +		dec_zone_page_state(page, NR_WRITEBACK);
     	return ret;
     }
     
    @@ -1012,6 +1014,8 @@ int test_set_page_writeback(struct page 
     	} else {
     		ret = TestSetPageWriteback(page);
     	}
    +	if (!ret)
    +		inc_zone_page_state(page, NR_WRITEBACK);
     	return ret;
     
     }
    _
    Another, hard to spot act of sabotage, occurs in reiser4/jnode.c, where the order of 2 lines has been swapped. This:

    Code:
    void jrelse_tail(jnode * node /* jnode to release references to */ )
    {
    	assert("nikita-489", atomic_read(&node->d_count) > 0);
    	atomic_dec(&node->d_count);
    	/* release reference acquired in jload_gfp() or jinit_new() */
    	jput(node);
    	if (jnode_is_unformatted(node) || jnode_is_znode(node))
    		LOCK_CNT_DEC(d_refs);
    }

  2. #2
    Join Date
    Sep 2006
    Posts
    353

    Default

    Another, hard to spot act of sabotage, occurs in reiser4/jnode.c, where the order of 2 lines has been swapped. This:

    Code:
    void jrelse_tail(jnode * node /* jnode to release references to */ )
    {
    	assert("nikita-489", atomic_read(&node->d_count) > 0);
    	atomic_dec(&node->d_count);
    	/* release reference acquired in jload_gfp() or jinit_new() */
    	jput(node);
    	if (jnode_is_unformatted(node) || jnode_is_znode(node))
    		LOCK_CNT_DEC(d_refs);
    }
    has been changed to this:

    Code:
    void jrelse_tail(jnode * node /* jnode to release references to */ )
    {
    	assert("nikita-489", atomic_read(&node->d_count) > 0);
    	atomic_dec(&node->d_count);
    	if (jnode_is_unformatted(node) || jnode_is_znode(node))
    		LOCK_CNT_DEC(d_refs);
    	/* release reference acquired in jload_gfp() or jinit_new() */
    	jput(node);
    }
    This is guaranteed to cause problems. If the original worked, then the change will not (and vica versa).

    Morton's patches contains the first, but not the second, sabotaged section of code.

  3. #3
    Join Date
    Sep 2006
    Posts
    353

    Default

    Thanks for the links, you should probably also put a link to the original this is based on (the Wired Blog).

    Remember that in the country this takes place (the murder trial), it doesn't matter what you think. It doesn't even matter what the jury itself thinks of the person's character or "acting strangely" (atleast it's not supposed to) - what matters is what you can prove.

    Guilt must be proven, a person is innocent until proven guilty in the USA. There has been a lot of conjecture and circumstantial evidence, which does not mean proof at all.

    As to the "kernel saboteurs", uhhmmmm. I have been a user of reiserfs3 for years and never noticed all these "issues" that people all of a sudden came up with (after Reiser was arrested). In fact I never was affected by any sort of corruption or whatnot - in 6+ years of using the filesystem (since 2.4.0)!

    ResierFS v4 is something I've wanted to try for a while, but it seems as if everytime I've gone to just do it that I've been "blocked" by one thing or another (boot CD lacks support, kernel patch is broken, developer kernel has bugs, etc.).

    The problem was not that I couldn't just use a NameSys patch on my own kernel (I used my own kernel anyway), and do a double install to get the main install up on v4, the issue was that the last time I looked the last patch I could find to be easily hacked to use a recent kernel (one I wanted) did not support compression. That is the sole reason for me wanting to migrate from v3 to v4, is the realtime compression (not for space increase, but for performance increase).

    What I can say from my experience personally is this:

    there were several reiserfs v4 patches in a certain kernel developer's tree that were not immediately apparant to be broken... but they were/are. An unnecessary kludge was introduced for no reason what-so-ever, which was the cause of the corruption. This developer is a very "big-name" person, and I will not tell you of whom I speak (this is not about flames, and I don't know why he did it i.e. a mistake or misunderstanding or what). Needless to say however, a lot of people use his patches for bleeding-edge features, mainly because he is supposed to be "dependable" and "official". So of course, eventually it was noticed - this few lines of code that was unecessarily introduced causing the coruption, and when asked he gave the most unbelievable answer. Then he proceeded to do a rewrite and what appeared as "cover his tracks".


    Anyhow that is what happened. Make of it what you will, but it surely was NOT bitrot or anything so simple...

    If you want to look at conspiracy theories, look at who the biggest sponsor was originally. There's your answer right there, and probably what they'd do to "get rid" of the filesystem (have the inventor locked away)

    BTW I've never understood the obsession about ext2 and ext3. ext2 was the worst filesystem I've used since the old days of UFS, and the only filesystems I've personally had explode were both ext2/ext3.

    I think I'll go install onto v4 now and do whatever necessary to get it done (if that means reintegrating compression back into the latest version then so be it). I want to do some benchmarks and stress-testing

    From: http://www.phoronix.com/forums/showp...5&postcount=45
    Last edited by Jade; 04-29-2008 at 01:44 AM.

  4. #4
    Join Date
    Sep 2006
    Posts
    353

    Default

    The above was posted by edged on 03-19-2008, 02:39 AM

  5. #5
    Join Date
    Sep 2006
    Posts
    353

    Default

    I tried asked him to what the "the most unbelievable answer" actually was. But as yet have no reply.

  6. #6
    Join Date
    Sep 2006
    Posts
    353

    Default

    I would dearly love to hear the reply -- anyone know it?

  7. #7
    Join Date
    May 2008
    Posts
    2

    Default Inventors murders

    Reiserfs is a new invention for this Earth Civilization that could make a revolution in a data storage.

    So occupation forces (sometimes referenced as "conspiracy theory") have had to stop reiserfs development or to keep it to be "file system" for all days.

    Killing Hans was not so easy as John Lennon for example, so Hans Reiser is in prison now.

    Here is more: http://www.totalizm.nazwa.pl/bandits.htm

    PS. I am using Reiserfs version 3 with several million files as a database with no problems

  8. #8
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote Originally Posted by memo2005 View Post
    Reiserfs is a new invention for this Earth Civilization that could make a revolution in a data storage.

    So occupation forces (sometimes referenced as "conspiracy theory") have had to stop reiserfs development or to keep it to be "file system" for all days.

    Killing Hans was not so easy as John Lennon for example, so Hans Reiser is in prison now.

    Here is more: http://www.totalizm.nazwa.pl/bandits.htm

    PS. I am using Reiserfs version 3 with several million files as a database with no problems
    This is indeed my belief as well.

  9. #9
    Join Date
    Sep 2006
    Posts
    353

    Default

    You can see that even those at this site feel guilty, as they try to hide this thread.

  10. #10
    Join Date
    Sep 2006
    Posts
    353

    Default

    Yes, some here feel VERY guilty, and hide this thread so it doesn't list on the front page as normal.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •