ceph-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Souptick Joarder <jrdr.linux@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, devel@lists.orangefs.org,
	ceph-devel@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-ext4@vger.kernel.org, ocfs2-devel@oss.oracle.com,
	linux-mtd@lists.infradead.org, dri-devel@lists.freedesktop.org,
	lustre-devel@lists.lustre.org,
	linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org
Subject: Re: vm_fault_t conversion, for real
Date: Wed, 16 May 2018 04:23:47 -0700	[thread overview]
Message-ID: <20180516112347.GB20670@bombadil.infradead.org> (raw)
In-Reply-To: <20180516054348.15950-1-hch@lst.de>

On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote:
> this series tries to actually turn vm_fault_t into a type that can be
> typechecked and checks the fallout instead of sprinkling random
> annotations without context.

Yes, why should we have small tasks that newcomers can do when the mighty
Christoph Hellwig can swoop in and take over from them?  Seriously,
can't your talents find a better use than this?

> The first one fixes a real bug in orangefs, the second and third fix
> mismatched existing vm_fault_t annotations on the same function, the
> fourth removes an unused export that was in the chain.  The remainder
> until the last one do some not quite trivial conversions, and the last
> one does the trivial mass annotation and flips vm_fault_t to a __bitwise
> unsigned int - the unsigned means we also get plain compiler type
> checking for the new ->fault signature even without sparse.

Yes, that was (part of) the eventual goal.  Well done.  Would you like
a biscuit?

  parent reply	other threads:[~2018-05-16 11:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-16  5:43 vm_fault_t conversion, for real Christoph Hellwig
2018-05-16  5:43 ` [PATCH 01/14] orangefs: don't return errno values from ->fault Christoph Hellwig
2018-05-16 11:18   ` Matthew Wilcox
2018-05-16  5:43 ` [PATCH 02/14] fs: make the filemap_page_mkwrite prototype consistent Christoph Hellwig
2018-05-16  5:43 ` [PATCH 03/14] dax: make the dax_iomap_fault " Christoph Hellwig
2018-05-16  5:43 ` [PATCH 04/14] mm: remove the unused device_private_entry_fault export Christoph Hellwig
2018-05-16  5:43 ` [PATCH 05/14] ceph: untangle ceph_filemap_fault Christoph Hellwig
2018-05-16  5:43 ` [PATCH 06/14] btrfs: separate errno from VM_FAULT_* values Christoph Hellwig
     [not found]   ` <20180516054348.15950-7-hch-jcswGhMUV9g@public.gmane.org>
2018-05-16 11:13     ` David Sterba
2018-05-16  5:43 ` [PATCH 07/14] ext4: " Christoph Hellwig
2018-05-16  5:43 ` [PATCH 08/14] ocfs2: " Christoph Hellwig
2018-05-16  5:43 ` [PATCH 09/14] ubifs: " Christoph Hellwig
2018-05-16  5:43 ` [PATCH 10/14] vgem: " Christoph Hellwig
2018-05-16  9:53   ` Daniel Vetter
2018-05-16 13:01     ` Christoph Hellwig
2018-05-16 13:13       ` Matthew Wilcox
2018-05-16  5:43 ` [PATCH 11/14] ttm: " Christoph Hellwig
2018-05-16  5:43 ` [PATCH 12/14] lustre: " Christoph Hellwig
2018-05-16  5:43 ` [PATCH 13/14] mm: move arch specific VM_FAULT_* flags to mm.h Christoph Hellwig
2018-05-16  5:43 ` [PATCH 14/14] mm: turn on vm_fault_t type checking Christoph Hellwig
2018-05-16 11:28   ` Matthew Wilcox
2018-05-16 13:03     ` Christoph Hellwig
2018-05-16 15:08   ` Darrick J. Wong
2018-05-16 17:34     ` Christoph Hellwig
2018-05-16 11:23 ` Matthew Wilcox [this message]
2018-05-16 13:03   ` vm_fault_t conversion, for real Christoph Hellwig
2018-05-16 13:22     ` Matthew Wilcox
2018-05-16 17:32       ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180516112347.GB20670@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=devel@lists.orangefs.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=jrdr.linux@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lustre-devel@lists.lustre.org \
    --cc=ocfs2-devel@oss.oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).