linux-kernel - Re: Device driver memory 'mmap()' function helper cleanup

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+55aFyVYBzOaTq2VTf2pZdV5Z=O94-Q+ZELYRJcQR3DPzC23A@mail.gmail.com>
Date:	Fri, 19 Apr 2013 16:07:29 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Michel Lespinasse <walken@...gle.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Clemens Ladisch <clemens@...isch.de>,
	Arnd Bergmann <arnd@...db.de>, Takashi Iwai <tiwai@...e.de>,
	Mauro Carvalho Chehab <mchehab@...hat.com>
Subject: Re: Device driver memory 'mmap()' function helper cleanup

On Fri, Apr 19, 2013 at 8:43 AM, Michel Lespinasse <walken@...gle.com> wrote:
>
> Just a suggestion: when file->f_op->mmap returns an error code,
> mmap_region() currently has to call unmap_region() to undo any partial
> mappings that might have been created by the device driver. Would it
> make more sense to ask that the few drivers that create such messes to
> clean up after themselves on their error paths ?

No. We basically want to assume the least competence humanly
(simianly?) possible from driver writers. The problem the helper is
trying to solve is exactly the fact that driver writers shouldn't have
to even know about all the subtleties with page offsets etc.

So if a driver returns an error code, we should assume they screwed up
potentially half-way and clean up. We should *not* assume that we
don't need to.

                   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/