From: Christoph Hellwig <hch@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
David Windsor <dave@nullcore.net>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v3 14/31] vxfs: Define usercopy region in vxfs_inode slab cache
Date: Wed, 20 Sep 2017 16:22:21 -0700 [thread overview]
Message-ID: <20170920232221.GA18311@infradead.org> (raw)
In-Reply-To: <CAGXu5j+hr0UwB5NsvPSKVVfM6NFHHhnNeUZbuwyTRppSOx9Ucw@mail.gmail.com>
On Wed, Sep 20, 2017 at 02:21:45PM -0700, Kees Cook wrote:
> This is why I included several other lists on the full CC (am I
> unlucky enough to have you not subscribed to any of them?). Adding a
> CC for everyone can result in a huge CC list, especially for the
> forth-coming 300-patch timer_list series. ;)
If you think the lists are enough to review changes include only
the lists, but don't add CCs for individual patches, that's what
I usually do for cleanups that touch a lot of drivers, but don't
really change actual logic in ever little driver touched.
> Do you want me to resend the full series to you, or would you prefer
> something else like a patchwork bundle? (I'll explicitly add you to CC
> for any future versions, though.)
I'm fine with not being Cced at all if there isn't anything requiring
my urgent personal attention. It's up to you whom you want to Cc,
but my preference is generally for rather less than more people, and
rather more than less mailing lists.
But the important bit is to Cc a person or mailinglist either on
all patches or on none, otherwise a good review isn't possible.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
David Windsor <dave@nullcore.net>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v3 14/31] vxfs: Define usercopy region in vxfs_inode slab cache
Date: Wed, 20 Sep 2017 16:22:21 -0700 [thread overview]
Message-ID: <20170920232221.GA18311@infradead.org> (raw)
In-Reply-To: <CAGXu5j+hr0UwB5NsvPSKVVfM6NFHHhnNeUZbuwyTRppSOx9Ucw@mail.gmail.com>
On Wed, Sep 20, 2017 at 02:21:45PM -0700, Kees Cook wrote:
> This is why I included several other lists on the full CC (am I
> unlucky enough to have you not subscribed to any of them?). Adding a
> CC for everyone can result in a huge CC list, especially for the
> forth-coming 300-patch timer_list series. ;)
If you think the lists are enough to review changes include only
the lists, but don't add CCs for individual patches, that's what
I usually do for cleanups that touch a lot of drivers, but don't
really change actual logic in ever little driver touched.
> Do you want me to resend the full series to you, or would you prefer
> something else like a patchwork bundle? (I'll explicitly add you to CC
> for any future versions, though.)
I'm fine with not being Cced at all if there isn't anything requiring
my urgent personal attention. It's up to you whom you want to Cc,
but my preference is generally for rather less than more people, and
rather more than less mailing lists.
But the important bit is to Cc a person or mailinglist either on
all patches or on none, otherwise a good review isn't possible.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
David Windsor <dave@nullcore.net>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH v3 14/31] vxfs: Define usercopy region in vxfs_inode slab cache
Date: Wed, 20 Sep 2017 16:22:21 -0700 [thread overview]
Message-ID: <20170920232221.GA18311@infradead.org> (raw)
In-Reply-To: <CAGXu5j+hr0UwB5NsvPSKVVfM6NFHHhnNeUZbuwyTRppSOx9Ucw@mail.gmail.com>
On Wed, Sep 20, 2017 at 02:21:45PM -0700, Kees Cook wrote:
> This is why I included several other lists on the full CC (am I
> unlucky enough to have you not subscribed to any of them?). Adding a
> CC for everyone can result in a huge CC list, especially for the
> forth-coming 300-patch timer_list series. ;)
If you think the lists are enough to review changes include only
the lists, but don't add CCs for individual patches, that's what
I usually do for cleanups that touch a lot of drivers, but don't
really change actual logic in ever little driver touched.
> Do you want me to resend the full series to you, or would you prefer
> something else like a patchwork bundle? (I'll explicitly add you to CC
> for any future versions, though.)
I'm fine with not being Cced at all if there isn't anything requiring
my urgent personal attention. It's up to you whom you want to Cc,
but my preference is generally for rather less than more people, and
rather more than less mailing lists.
But the important bit is to Cc a person or mailinglist either on
all patches or on none, otherwise a good review isn't possible.
next prev parent reply other threads:[~2017-09-20 23:22 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 20:45 [PATCH v3 00/31] Hardened usercopy whitelisting Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 01/31] usercopy: Prepare for " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 15:21 ` Christopher Lameter
2017-09-21 15:21 ` [kernel-hardening] " Christopher Lameter
2017-09-20 20:45 ` [PATCH v3 02/31] usercopy: Enforce slab cache usercopy region boundaries Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 15:23 ` Christopher Lameter
2017-09-21 15:23 ` [kernel-hardening] " Christopher Lameter
2017-09-20 20:45 ` [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 15:27 ` Christopher Lameter
2017-09-21 15:27 ` [kernel-hardening] " Christopher Lameter
2017-09-21 15:40 ` Kees Cook
2017-09-21 15:40 ` Kees Cook
2017-09-21 15:40 ` Kees Cook
2017-09-21 16:04 ` Christopher Lameter
2017-09-21 16:04 ` Christopher Lameter
2017-09-21 18:26 ` Kees Cook
2017-09-21 18:26 ` Kees Cook
2017-09-21 18:26 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 04/31] dcache: Define usercopy region in dentry_cache slab cache Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 05/31] vfs: Define usercopy region in names_cache slab caches Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 06/31] vfs: Copy struct mount.mnt_id to userspace using put_user() Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 07/31] ext4: Define usercopy region in ext4_inode_cache slab cache Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 08/31] ext2: Define usercopy region in ext2_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 09/31] jfs: Define usercopy region in jfs_ip " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-22 2:54 ` Dave Kleikamp
2017-09-22 2:54 ` [kernel-hardening] " Dave Kleikamp
2017-09-22 2:54 ` Dave Kleikamp
2017-09-20 20:45 ` [PATCH v3 10/31] befs: Define usercopy region in befs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 9:34 ` Luis de Bethencourt
2017-09-21 9:34 ` [kernel-hardening] " Luis de Bethencourt
2017-09-21 9:34 ` Luis de Bethencourt
2017-09-20 20:45 ` [PATCH v3 11/31] exofs: Define usercopy region in exofs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 12/31] orangefs: Define usercopy region in orangefs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 13/31] ufs: Define usercopy region in ufs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 14/31] vxfs: Define usercopy region in vxfs_inode " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:56 ` Christoph Hellwig
2017-09-20 20:56 ` [kernel-hardening] " Christoph Hellwig
2017-09-20 20:56 ` Christoph Hellwig
2017-09-20 21:21 ` Kees Cook
2017-09-20 21:21 ` [kernel-hardening] " Kees Cook
2017-09-20 21:21 ` Kees Cook
2017-09-20 23:22 ` Christoph Hellwig [this message]
2017-09-20 23:22 ` [kernel-hardening] " Christoph Hellwig
2017-09-20 23:22 ` Christoph Hellwig
2017-09-20 23:22 ` Christoph Hellwig
2017-09-20 20:45 ` [PATCH v3 15/31] xfs: Define usercopy region in xfs_inode " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
[not found] ` <1505940337-79069-1-git-send-email-keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2017-09-20 20:45 ` [PATCH v3 16/31] cifs: Define usercopy region in cifs_request " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 17/31] scsi: Define usercopy region in scsi_sense_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 18/31] net: Define usercopy region in struct proto " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 19/31] ip: Define usercopy region in IP " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 20/31] caif: Define usercopy region in caif " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 21/31] sctp: Define usercopy region in SCTP " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 22/31] sctp: Copy struct sctp_sock.autoclose to userspace using put_user() Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 23/31] net: Restrict unwhitelisted proto caches to size 0 Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 24/31] fork: Define usercopy region in mm_struct slab caches Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 25/31] fork: Define usercopy region in thread_stack " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 26/31] fork: Provide usercopy whitelisting for task_struct Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 27/31] x86: Implement thread_struct whitelist for hardened usercopy Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 28/31] arm64: " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 29/31] arm: " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 30/31] usercopy: Restrict non-usercopy caches to size 0 Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 31/31] lkdtm: Update usercopy tests for whitelisting Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
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=20170920232221.GA18311@infradead.org \
--to=hch@infradead.org \
--cc=dave@nullcore.net \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.