linux-kernel - Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock

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: <CA+55aFyLPpDzgYJfXFMMGaWT4JOsSN0be_ntazjzc+GEg14V2A@mail.gmail.com>
Date:	Fri, 1 Nov 2013 11:55:03 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Michel Lespinasse <walken@...gle.com>
Cc:	Andrea Arcangeli <aarcange@...hat.com>,
	Davidlohr Bueso <davidlohr@...com>,
	Ingo Molnar <mingo@...nel.org>,
	Yuanhan Liu <yuanhan.liu@...ux.intel.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Davidlohr Bueso <davidlohr.bueso@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t

On Fri, Nov 1, 2013 at 11:47 AM, Michel Lespinasse <walken@...gle.com> wrote:
>
> Should copy Andrea on this. I talked with him during KS, and there are
> no current in-tree users who are doing such sleeping; however there
> are prospective users for networking (RDMA) or GPU stuff who want to
> use this to let hardware directly copy data into user mappings.

Tough.

I spoke up the first time this came up and I'll say the same thing
again: we're not screwing over the VM subsystem because some crazy
user might want to do crazy and stupid things that nobody sane cares
about.

The whole "somebody might want to .." argument is just irrelevant.
Some people want to sleep in interrupt handlers too, or while holding
random spinlocks. Too bad. They don't get to, because doing that
results in problems for the rest of the system.

Our job in the kernel is to do the best job technically that we can.
And sometimes that very much involves saying "No, you can't do that".

We have limitations in the kernel. The stack is of limited size. You
can't allocate arbitrarily sized memory. You must follow some very
strict rules.

If people can't handle that, then they can go cry to mommy, and go
back to writing user mode code. In the kernel, you have to live with
certain constraints that makes the kernel better.

               Linus
--
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/