From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: David Windsor <dwindsor@gmail.com>,
Kees Cook <keescook@chromium.org>,
Peter Zijlstra <peterz@infradead.org>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"Anvin, H Peter" <h.peter.anvin@intel.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"ishkamiel@gmail.com" <ishkamiel@gmail.com>
Subject: Re: [kernel-hardening] [RFC PATCH 08/19] kernel, mm: convert from atomic_t to refcount_t
Date: Wed, 18 Jan 2017 10:03:40 +0100 [thread overview]
Message-ID: <20170118090340.GB2043@kroah.com> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B41C3E725@IRSMSX102.ger.corp.intel.com>
On Wed, Jan 18, 2017 at 08:41:17AM +0000, Reshetova, Elena wrote:
> > Do you have any particular workload that you've been testing these with?
>
> No, we only tested the full boot, that's why I would like to understand how to test more.
> I think it is not so much about the workload, but about testing
> different configuration. Like for example, when AKASHI Takahiro run
> the patches on top on NFS rootfs, it has shown the issue we haven't
> seen in our case. You can imagine how many of such cases are still
> hiding given the number of configurations and drivers that get active
> in runtime.
That is why you need to post the patches so that the subsystem
maintainers can review them! They are the ones that know the code the
best, why you all don't want to let them at least review the changes is
beyond me...
greg k-h
next prev parent reply other threads:[~2017-01-18 9:03 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 6:55 [kernel-hardening] [RFC PATCH 00/19] refcount_t API + usage Elena Reshetova
2016-12-29 6:55 ` [kernel-hardening] [RFC PATCH 01/19] Since we need to change the implementation, stop exposing internals. Provide kref_read() to read the current reference count; typically used for debug messages Elena Reshetova
2016-12-29 16:41 ` [kernel-hardening] " Greg KH
2016-12-29 16:49 ` Reshetova, Elena
2016-12-30 7:58 ` Greg KH
2016-12-30 12:50 ` Reshetova, Elena
2016-12-29 6:55 ` [kernel-hardening] [RFC PATCH 02/19] By general sentiment kref_sub() is a bad interface, make it go away Elena Reshetova
2016-12-29 6:55 ` [kernel-hardening] [RFC PATCH 03/19] For some obscure reason apparmor thinks its needs to locally implement kref primitives that already exist. Stop doing this Elena Reshetova
2016-12-29 6:55 ` [kernel-hardening] [RFC PATCH 04/19] Because home-rolling your own is _awesome_, stop doing it. Provide kref_put_lock(), just like kref_put_mutex() but for a spinlock Elena Reshetova
2016-12-29 6:55 ` [kernel-hardening] [RFC PATCH 05/19] Leak references by unbalanced get, instead of poking at kref implementation details Elena Reshetova
2016-12-29 6:55 ` [kernel-hardening] [RFC PATCH 06/19] Provide refcount_t, an atomic_t like primitive built just for refcounting Elena Reshetova
2016-12-30 1:06 ` Eric Biggers
2016-12-30 13:17 ` Reshetova, Elena
2016-12-30 19:52 ` Eric Biggers
2017-01-03 13:21 ` Peter Zijlstra
2017-01-04 20:36 ` Eric Biggers
2017-01-05 10:44 ` Peter Zijlstra
2017-01-05 21:21 ` PaX Team
2017-01-20 10:35 ` Greg KH
2017-01-20 13:10 ` Peter Zijlstra
2016-12-29 6:55 ` [kernel-hardening] [RFC PATCH 07/19] mixed: kref fixes Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 08/19] kernel, mm: convert from atomic_t to refcount_t Elena Reshetova
2017-01-05 2:25 ` AKASHI Takahiro
2017-01-05 9:56 ` Reshetova, Elena
2017-01-05 19:33 ` Kees Cook
2017-01-10 11:57 ` Reshetova, Elena
2017-01-10 20:34 ` Kees Cook
2017-01-11 9:30 ` Reshetova, Elena
2017-01-11 21:42 ` Kees Cook
2017-01-11 22:55 ` Kees Cook
2017-01-12 2:55 ` Kees Cook
2017-01-12 8:02 ` Reshetova, Elena
2017-01-12 5:11 ` AKASHI Takahiro
2017-01-12 8:18 ` Reshetova, Elena
2017-01-12 8:57 ` Peter Zijlstra
2017-01-16 16:16 ` Reshetova, Elena
2017-01-17 17:15 ` Kees Cook
2017-01-17 17:44 ` Reshetova, Elena
2017-01-17 17:50 ` David Windsor
2017-01-18 8:41 ` Reshetova, Elena
2017-01-18 9:03 ` gregkh [this message]
2017-01-18 9:14 ` Reshetova, Elena
2017-01-17 18:26 ` gregkh
2017-01-12 7:57 ` Reshetova, Elena
2017-01-12 7:54 ` Reshetova, Elena
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 09/19] net: " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 10/19] fs: " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 11/19] security: " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 12/19] sound: " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 13/19] ipc: covert " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 14/19] tools: convert " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 15/19] block: " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 16/19] drivers: net " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 17/19] drivers: misc " Elena Reshetova
2016-12-29 6:56 ` [kernel-hardening] [RFC PATCH 18/19] drivers: infiniband " Elena Reshetova
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=20170118090340.GB2043@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=dwindsor@gmail.com \
--cc=elena.reshetova@intel.com \
--cc=h.peter.anvin@intel.com \
--cc=ishkamiel@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=takahiro.akashi@linaro.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.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 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.