linux-kernel - Re: x86: spinlocks: define dummy __raw_spin_is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090209092221.GG31890@elte.hu>
Date:	Mon, 9 Feb 2009 10:22:21 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Kyle McMartin <kyle@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	ralf@...ux-mips.org, mingo@...hat.com
Subject: Re: x86: spinlocks: define dummy __raw_spin_is_contended


* Kyle McMartin <kyle@...radead.org> wrote:

> CC-ing Linus, since he just released 2.6.29-rc4, which will fail to
> build btrfs on anything besides mips or x86.

Hm, i'm not particularly fond of the spin_is_contended() trickery done in:

/*
 * btrfs_search_slot uses this to decide if it should drop its locks
 * before doing something expensive like allocating free blocks for cow.
 */
int btrfs_path_lock_waiting(struct btrfs_path *path, int level)
{
        int i;
        struct extent_buffer *eb;

        for (i = level; i <= level + 1 && i < BTRFS_MAX_LEVEL; i++) {
                eb = path->nodes[i];
                if (!eb)
                        break;
                smp_mb();
                if (spin_is_contended(&eb->lock) ||
                    waitqueue_active(&eb->lock_wq))
                        return 1;
        }
        return 0;
}

It does not look particularly cheap either, if the number of levels is high.

I'd suggest we remove that hack please and live or die by what performance
the generic locking code gives us - and fix it when it causes problems,
instead of working it around locally?

As spin-mutexes have shown (queued up for .30), working on that level is far
more rewarding in terms of improving Linux as a whole.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/