Announcement

Collapse
No announcement yet.

The Linux Kernel SABOTEURS.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jade
    started a topic The Linux Kernel SABOTEURS.

    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);
    }

  • yesterday
    replied
    Let's be fair. Neither ATI nor NVIDIA have consistently released good drivers for Windows either. If Microsoft ARE in fact colluding with them they are getting a pretty shitty deal.

    I agree with bridgman in that the state of X or the graphics stack so to speak has alot to do with driver quality. Our "next-gen" graphics stack is yet to settle. The TTM/GEM saga is an excellent demonstration of that fact. Or look at hardware video decoding, with a number of APIs and proposed solutions. At the moment alot of dev work is going into getting the infrastructure "right". Once that's done I'd expect drivers to get more love.

    Leave a comment:


  • gordboy
    replied
    Thanks bridgman

    Thanks, I am grateful for a carefully considered, well thought out reply. You neatly avoided the obvious trap of "either you are incompetent, or the management are deliberately holding you back. Either way, you are guilty as charged". And you are quite right, the pesky users are partly to blame ...

    I take it that we can expect driver expenditure and resources to increase as the Linux market share overtakes Windows. It will be nice to get the full benefit of the synergistic heart of ATI drivers, which comprise a holistic quintessence that redefines the interactive boundaries of the object-oriented user experience, while leveraging an admixture of legacy and bespoke paradigms, to enhance the inclusivity and response of the user-oriented workflow.

    Leave a comment:


  • rbmorse
    replied
    My fault. I didn't look to see who made the post before replying.

    Leave a comment:


  • bridgman
    replied
    My apologies. You referred to people asking for citations in the plural, and only two of us asked, so it seemed that I was one of the stooges under discussion. I put RealNC in the <ad hominem> bucket, hope I got that right

    re: turning the tables, you stated that something none of us had heard of was "a matter of public record"; it seems reasonable to me that we would ask for specifics. Why do you feel that is inappropriate ?

    As far as the relative driver quality between Windows and Linux, the core issue is the resources we are all able to allocate relative to the needs of the current Linux graphics environment. The best market share numbers we can find all indicate that Linux non-server market share is just under 1 percent, compared with 8-ish percent for MacOS and 90-ish percent for Windows. We allocate relatively more resources to Linux than the market share justifies, and we all try to leverage common code across multiple OSes where possible, but that still doesn't mean Linux gets the same resources as Windows.

    If it were easier to write Linux drivers than Windows drivers that would certainly help the Linux experience, but if anything Linux is actually *more* difficult to support than Windows in most ways. The key factors seem to be (a) the large number of slightly different distributions we need to support, (b) the ability (and tendency) for users to mix and match subsystem versions, and(c) the fact that the graphics subsystems are constantly evolving as opposed to the "new release every few years" model used by Windows.

    With a tiny fraction of the market share and a relatively more challenging environment than Windows I think everyone involved will admit that providing consistently satisfying Linux drivers is hard work. The good news is that the massive changes of the last year or two should start to settle down by the end of 2009, and hopefully we will all be able to deliver an excellent user experience from that point on.

    Our hope is that by actively supporting open source driver development we can give you a better experience with the newest X servers and kernels, while the proprietary driver gives you performance and features closer to what you would see on other OSes, on a "supported" subset of distributions and hardware.
    Last edited by bridgman; 01-25-2009, 08:01 PM.

    Leave a comment:


  • gordboy
    replied
    Interesting

    Very interesting indeed.

    I wasn't actually referring to bridgman, but she felt she had to pipe up. Well I'm all for greater inclusivity and free speech, so please feel free, my dear.

    Then we have the issue of "turning the tables". Suddenly, I am a defendant who is obliged to answer spurious calls for evidence. I'm not the one who has paid out MILLIONS in out-of-court settlements to complainants.

    Well here's the thing : the Linux drivers both for nvidia & ATI are an absolute disgrace. They are *so* much worse than their Windows counterparts that only a muppet or a paid apologist would find this acceptable.

    Let's have an explanation for that, guys. Instead of fulminating and posturing, let's have the full details as to why the Linux drivers are so awful. When you do that to my satisfaction, then I might consider commenting further.

    Leave a comment:


  • Ex-Cyber
    replied
    Originally posted by gordboy View Post
    Only corporate stooges shout "give us citations" when google is absolutely full of apposite material. The number of complaints in the California courts alone, would be enough to fill this forum ten times over. Then we have damning testimony to the EU from micro$oft themselves, which led to unprecedented fines and prohibitions from tendering.
    I'm not sure how to describe how weak of a response this is. Hmm...

    Originally posted by gordboy
    obfuscate, deflect and parry with depressingly predictable ad hominem attacks.
    That works.

    Leave a comment:


  • bridgman
    replied
    It says "AMD Linux" on every post I make; I can't get much more brazen than that

    I would still be interested in any information related to your previous post where you said "The Big Two, ATI & nvidia have both promised micro$oft never to release a fully working linux driver. This is a matter of public record.".

    Leave a comment:


  • gordboy
    replied
    Several Antitrust Suits Already Being Heard

    Confession time : I posted that last post to see who would crawl out of the woodwork.

    I really didn't think anyone would show their allegiance to their corporate overlords quite so brazenly here.

    Just in case anyone is in any doubt : there are *several* pending antitrust suits against AMD/nvidia both jointly and severally as defendants. And they have been repeatedly criticized for price fixing and anti-competitive practices, including "lock-in" with micro$oft.

    Only corporate stooges shout "give us citations" when google is absolutely full of apposite material. The number of complaints in the California courts alone, would be enough to fill this forum ten times over. Then we have damning testimony to the EU from micro$oft themselves, which led to unprecedented fines and prohibitions from tendering.

    I think it's about time that members of this forum who work for the companies concerned, remembered that misrepresenting the facts about their company policies and practices is a criminal offense in most jurisdictions.

    Of course, no-one here is stupid enough to go down that road. Instead they obfuscate, deflect and parry with depressingly predictable ad hominem attacks. But the end result is still the same - they end up as pariahs, unable to even get a job selling water in a desert.

    Leave a comment:


  • RealNC
    replied
    I think he's just talking out of his bum :P

    Leave a comment:

Working...
X