Acked-by: Geert Uytterhoeven
Signed-off-by: James Bottomley
---
v2: Added this patch to allay concerns we were stripping the reporting
mechanism entirely.
v3: Add (where required by law) as a qualifier to the confidentiality
requirement
---
Documentation/process/code-of-conduct.rst | 11
: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Shuah Khan
Acked-by: Guenter Roeck
Acked-by: Geert Uytterhoeven
Reviewed-by: Alan Cox
Signed-off-by: James Bottomley
---
v2: Added additional commit paragraph clarifying we do expect eventually to
have an enforcem
uot;
Acked-by: Kees Cook
Signed-off-by: James Bottomley
---
Documentation/process/code-of-conduct.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/code-of-conduct.rst
b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..aa40e34e7785 100644
--
h all and ksummit-discuss since
that's where most of the current discussion is. I can add other lists
as people suggest them.
James
---
James Bottomley (3):
code-of-conduct: Fix the ambiguity about collecting email addresses
code-of-conduct: Strip the enforcement paragraph pending comm
On Fri, 2018-10-12 at 10:53 -0500, Denis Kenzior wrote:
> Hi James,
>
> > > From the links provided in the patch it seems that one cannot
> > > pass char/float/short to va_start(). Fair enough. So if we make
> > > h3 an unsigned int, the issue goes away, no?
> >
> > For the current version of
On Fri, 2018-10-12 at 10:44 -0500, Denis Kenzior wrote:
> Hi James,
>
> > > So instead of having unsigned char h3, can't we simply have bool
> > > h3 or unsigned int h3?
> >
> > Given the ambiguity in the standards, the safe thing that will work
> > for all time and all potential compilers is a c
On Fri, 2018-10-12 at 10:13 -0500, Denis Kenzior wrote:
> Hi James,
>
> > > So can't we simply use 'bool' or uint32 as the type for h3
> > > instead
> > > of re-ordering everything
> >
> > The problem is the standard is ambiguious. The only thing that's
> > guaranteed to work for all time is a c
On Fri, 2018-10-12 at 10:13 -0500, Denis Kenzior wrote:
> Hi James,
>
> > > So can't we simply use 'bool' or uint32 as the type for h3
> > > instead of re-ordering everything
> >
> > The problem is the standard is ambiguious. The only thing that's
> > guaranteed to work for all time is a char *.
On Fri, 2018-10-12 at 07:29 -0500, Denis Kenzior wrote:
> Hi Nick,
>
> > @@ -123,7 +123,7 @@ static int TSS_rawhmac(unsigned char *digest,
> > const unsigned char *key,
> >*/
> > static int TSS_authhmac(unsigned char *digest, const unsigned
> > char *key,
> > unsigned int
On Thu, 2018-10-11 at 18:02 +0200, Arnd Bergmann wrote:
> On 10/10/18, Nick Desaulniers wrote:
> > Hello,
> > I noticed that compiling with
> > CONFIG_TCG_TPM=y
> > CONFIG_HW_RANDOM_TPM=y
> > and Clang produced the warning:
> >
> > CC security/keys/trusted.o
> > security/keys/trusted.c:146
On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote:
> James Bottomley writes:
>
> > Resend to show accumulated tags and also to add a third patch
> > listing the TAB as the reporting point as a few people seem to
> > want. If it gets the same level of suppo
On Wed, 2018-10-10 at 21:04 +, Luck, Tony wrote:
> > the enforcement clause of the new code of conduct. Since there is
> > concern that this becomes binding on the release of the 4.19 kernel
>
> Is there some logic behind that concern?
Well, yes, Linux as a project goes through numbered rele
Add a Reporting section where the Enforcement section used to be. The
intention is still to debate what should go here, but in the meantime, this
gives us back the central reporting point we had in the old code of conflict.
Signed-off-by: James Bottomley
---
v2: Added this patch to allay
: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Shuah Khan
Acked-by: Guenter Roeck
Acked-by: Geert Uytterhoeven
Reviewed-by: Alan Cox
Signed-off-by: James Bottomley
---
v2: Added additional commit paragraph clarifying we do expect eventually to
have an enforcem
collected by
the project to correct this ambiguity.
Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Geert Uytterhoeven
Acked-by: Shuah Khan
Acked-by: Guenter Roeck
Reviewed-by: Alan Cox
Reviewed-by: Mauro Carvalho Chehab
Signed-off-by: James Bottomley
---
y are separable if one is looked on with less favour
than the other.
It was also a bit unclear which list to send this to, but I finally
settled on linux-kernel as the catch all and ksummit-discuss since
that's where most of the current discussion is. I can add other lists
as people su
> > > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley
> > > > wrote:
> > > > > The current code of conduct has an ambiguity in the it
> > > > > considers publishing private information such as email
> > > > > addresses un
On Mon, 2018-10-08 at 17:58 +, tim.b...@sony.com wrote:
> > -Original Message-
> > From: James Bottomley
> >
> > On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote:
> > > > -Original Message-
> > > > From: James Bot
On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote:
> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> > The current code of conduct has an ambiguity in the it considers
> > publishing private information such as email addresses unacceptable
> > behavi
On Mon, 2018-10-08 at 13:51 +, tim.b...@sony.com wrote:
> > -Original Message-
> > From: James Bottomley
> > On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote:
> > > > -Original Message-
> > > > From: James Bottomley
>
On Mon, 2018-10-08 at 08:25 +1000, Dave Airlie wrote:
> On Sun, 7 Oct 2018 at 07:36, James Bottomley
> wrote:
> >
> > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00
> > 2001
> > From: James Bottomley
> > Date: Sat, 6 Oct 2018 14:21:56 -0
On Sun, 2018-10-07 at 19:11 +0200, Daniel Vetter wrote:
> Hi James,
>
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> wrote:
> > We've had several threads discussing potential changes to the code
> > of
> > conduct but Mauro is the only person to have p
On Sun, 2018-10-07 at 11:04 +0200, Daniel Vetter wrote:
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> wrote:
> >
> > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00
> > 2001
> > From: James Bottomley
> > Date: Sat, 6 Oct 2018 14:21:56
On Sat, 2018-10-06 at 21:43 +, tim.b...@sony.com wrote:
> > -Original Message-
> > From: James Bottomley
> >
> > Significant concern has been expressed about the responsibilities
> > outlined in the enforcement clause of the new code of
> > conduc
this
should be handled.
Signed-off-by: James Bottomley
---
Documentation/process/code-of-conduct.rst | 15 ---
1 file changed, 15 deletions(-)
diff --git a/Documentation/process/code-of-conduct.rst
b/Documentation/process/code-of-conduct.rst
index aa40e34e7785..4dd90987305b 100644
>From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
From: James Bottomley
Date: Sat, 6 Oct 2018 14:21:56 -0700
Subject: [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email
addresses
The current code of conduct has an ambiguity in the it considers publish
discussion is. I can add other lists
as people suggest them.
James
---
James Bottomley (2):
code-of-conduct: Fix the ambiguity about collecting email addresses
code-of-conduct: Strip the enforcement paragraph pending community
discussion
Documentation/process/code-of-conduct.rst | 17
On Wed, 2018-10-03 at 21:31 -0300, Leonardo Bras wrote:
> On Fri, Sep 28, 2018 at 4:15 AM James Bottomley
> wrote:
> >
> > On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote:
> > > Avoids building driver if 'make drivers/parisc/' is called and
> &g
On Tue, 2018-10-02 at 18:47 +0200, Laurent Vivier wrote:
> Le 02/10/2018 à 18:13, James Bottomley a écrit :
> > On Tue, 2018-10-02 at 12:20 +0200, Laurent Vivier wrote:
> > > v2: no new namespace, binfmt_misc data are now part of
> > > the mount namespace
&g
On Tue, 2018-10-02 at 12:20 +0200, Laurent Vivier wrote:
> v2: no new namespace, binfmt_misc data are now part of
> the mount namespace
> I put this in mount namespace instead of user namespace
> because the mount namespace is already needed and
> I don't want to force to have the u
On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote:
> Avoids building driver if 'make drivers/parisc/' is called and
> CONFIG_PARISC is disabled.
Is that really a problem? The drivers/Makefile has this:
obj-$(CONFIG_PARISC)+= parisc/
And you just overrode that by forcing the buil
: Paul E. McKenney
> Cc: Douglas Miller
> Cc: Eddie James
> Cc: Frank Haverkamp
> Cc: Frederic Barrat
> Cc: James Bottomley
Acked-by: James Bottomley
James
On Tue, 2018-09-18 at 08:00 +0100, David Woodhouse wrote:
>
> On Sat, 2018-09-08 at 16:26 +0100, David Howells wrote:
> > Marcel Holtmann wrote:
> >
> > >
> > > so I have reviewed and tested this code. In addition, we have
> > > test cases for it in ELL (embedded linux library).
> >
> > I wond
On Sun, 2018-09-16 at 22:19 +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 13, 2018 at 05:45:54PM +0100, David Howells wrote:
> > Jarkko Sakkinen wrote:
> >
> > > David, what do you think?
> >
> > Which David?
> >
> > I think you need to ask James and Mimi since they're the current
> > maintainers
On Wed, 2018-09-05 at 12:25 -0400, Martin K. Petersen wrote:
> Jens,
>
> > I bet it's the host busy change from Ming, which I already
> > reported as being the culprit for another test failure I had. For
> > some reason it's not merged yet, nudge nudge Martin.
>
> I reverted the two offending cha
On Mon, 2018-08-20 at 21:52 +, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> >
> > Of course, after the long (and entirely unrelated) discussion about
> > the TLB flushing bug we had, I'm starting to worry about my own
> > competence, and maybe I'm missin
On Fri, 2018-08-17 at 10:42 -0500, Justin Forbes wrote:
> On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
> wrote:
> > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
[...]
> > > We also don't necessarily want to encourage ordinary users to
> > > f
On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > > > As a step by step process, I agree. However, I think we can
> > > > automate it to the point where you install a package and it
> > > > says "insert
On Thu, 2018-08-16 at 21:31 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > As a step by step process, I agree. However, I think we can
> > automate it to the point where you install a package and it says
> > "insert your yubikey" every time you upg
On Thu, 2018-08-16 at 16:56 +, David Laight wrote:
> From: James Bottomley
> > Sent: 16 August 2018 16:57
> > On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote:
> > > James Bottomley wrote:
> > >
> > > > > The problem with that is th
On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > > The problem with that is that it means you can't load third party
> > > modules - such as the NVidia driver. That's fine if you
> > > absolutely reject
On Thu, 2018-08-16 at 08:16 -0700, James Bottomley wrote:
> So your lawyers tell you if you sign a third party module for your
> kernel then you could get blamed for the damage it causes? So this
> whole escapade is about Red Hat trying to evade legal responsibility
> for allowing
On Thu, 2018-08-16 at 14:51 +0100, David Howells wrote:
> Linus Torvalds wrote:
>
> > > I see that module signing code trusts only builtin keys and
> > > not the keys in secondary_trusted_keys keyring.
> >
> > This, I think, makes sense.
> >
> > It basically says: we don't allow modules that we
On Thu, 2018-08-16 at 15:43 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > I've told you several times you can't use the secure boot keys for
> > any form
> > of trust beyond boot,
>
> Yes - and you've been told several times that you
On Thu, 2018-08-16 at 13:13 +0100, David Howells wrote:
> Vivek Goyal wrote:
>
> > Now this patch changed it to trusting builtin_trusted_keys by
> > default, and all the other keys go to secondary_trusted_keys
> > kerying. And that probably explains why it broke.
> >
> > So checking for keys in
On Wed, 2018-08-15 at 17:52 -0400, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote:
> > On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> > > On 15.08.2018 22:47, Linus Torvalds wrote:
> > > > It basically says: we do
On Wed, 2018-08-15 at 23:31 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but
> > which
> > has some signed ROMs which are UEFI secure boot verified. Simply
> > to
>
On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 22:47, Linus Torvalds wrote:
> > It basically says: we don't allow modules that weren't built with
> > the kernel. Adding a new key later and signing a module with it
> > violates that premise.
>
> Considering the followin
On Wed, 2018-08-15 at 13:47 -0700, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal
> wrote:
> >
> > I see that module signing code trusts only builtin keys and
> > not the keys in secondary_trusted_keys keyring.
>
> This, I think, makes sense.
>
> It basically says: we don'
8360ebc8cce888e883d2b274445eace901276237
Merge: 94710cac0ef4 51372570ac3c
Author: James Bottomley
Date: Wed Aug 15 10:29:51 2018 -0700
Merge branch 'misc' into for-next
diff --cc MAINTAINERS
index 544cac829cf4,f3de5d37179a..eeb54037b62d
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -9751
On Fri, 2018-08-10 at 11:56 -0700, Tadeusz Struk wrote:
> On 08/10/2018 11:48 AM, James Bottomley wrote:
> > On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
> > > and the feedback I got from Jason was:
> > >
> > > "I wonder if it is worth creating
On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
> and the feedback I got from Jason was:
>
> "I wonder if it is worth creating this when the first file is
> opened.. Lots of systems have TPMs but few use the userspace.."
>
> so I changed this to allocate the WQ on first open. I think it m
On Mon, 2018-08-06 at 20:44 -0600, Tycho Andersen wrote:
> Hi all,
>
> Dinesh Subhraveti has claimed that some part of this series might be
> patented. While he has not furnished me with anything to confirm this
> claim, I'll put this series on hold.
Just on a general policy for handling things l
On Mon, 2018-08-06 at 17:09 -0700, Tadeusz Struk wrote:
> On 08/06/2018 04:05 PM, James Bottomley wrote:
> > For an async interface, shouldn't I be able to queue an
> > arbitrary number of commands without blocking?
>
> That was the approach in the v1 version of this pa
On Mon, 2018-08-06 at 14:14 -0700, Tadeusz Struk wrote:
[...]
> +static void tpm_async_work(struct work_struct *work)
> +{
> + struct file_priv *priv =
> + container_of(work, struct file_priv,
> async_work);
> + ssize_t ret;
> +
> + ret = tpm_transmit(priv->chip, pri
On Fri, 2018-08-03 at 10:45 -0400, Mimi Zohar wrote:
> On Fri, 2018-08-03 at 07:23 -0700, James Bottomley wrote:
> > On Fri, 2018-08-03 at 07:58 -0400, Mimi Zohar wrote:
> > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:
> >
On Fri, 2018-08-03 at 07:58 -0400, Mimi Zohar wrote:
> On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:
> > Udit Agarwal wrote:
> >
> > > +==
> > > +Secure Key
> > > +==
> > > +
> > > +Secure key is the new type added to kernel key ring service.
> > > +Secure key is a symme
On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:
> Udit Agarwal wrote:
>
> > +==
> > +Secure Key
> > +==
> > +
> > +Secure key is the new type added to kernel key ring service.
> > +Secure key is a symmetric type key of minimum length 32 bytes
> > +and with maximum possible
On Mon, 2018-07-23 at 13:53 -0700, Tadeusz Struk wrote:
> On 07/23/2018 01:19 PM, Jarkko Sakkinen wrote:
> > In this case I do not have any major evidence of any major benefit
> > *and* the change breaks the ABI.
>
> As I said before - this does not break the ABI.
The current patch does, you even
On Thu, 2018-07-19 at 13:12 -0700, Tadeusz Struk wrote:
> On 07/19/2018 12:52 PM, James Bottomley wrote:
> > The ABI break is the error case as I outlined above. We can't
> > assume everyone uses the current interface without getting an error
> > and one error and you
On Thu, 2018-07-19 at 12:05 -0700, Tadeusz Struk wrote:
> On 07/19/2018 11:47 AM, James Bottomley wrote:
> > On Thu, 2018-07-19 at 10:54 -0700, Tadeusz Struk wrote:
> > > On 07/19/2018 10:19 AM, James Bottomley wrote:
> > > > That's just an implemen
On Thu, 2018-07-19 at 10:54 -0700, Tadeusz Struk wrote:
> On 07/19/2018 10:19 AM, James Bottomley wrote:
> > That's just an implementation, though, what's the use case?
>
> Hi James,
> The use case is described in the TCTI spec [1] in the
> "3.2.5.2 receive&quo
On Thu, 2018-07-19 at 08:52 -0700, Tadeusz Struk wrote:
> Currently to read a response from the TPM device an application needs
> provide "big enough" buffer for the whole response and read it in one
> go. The application doesn't know how big the response it beforehand
> so it always needs to main
On Tue, 2018-07-10 at 08:22 -0600, Jens Axboe wrote:
> On 7/10/18 8:14 AM, James Bottomley wrote:
> > On Tue, 2018-07-10 at 08:09 -0600, Jens Axboe wrote:
> > > On 7/10/18 1:31 AM, Stephen Rothwell wrote:
> >
> > [...]
> > > > I am still seeing these warn
On Tue, 2018-07-10 at 08:09 -0600, Jens Axboe wrote:
> On 7/10/18 1:31 AM, Stephen Rothwell wrote:
[...]
> > I am still seeing these warnings ...
>
> Martin queued up the forward declaration patch for this one, not sure
> why it isn't showing up in the scsi tree yet.
All the trees are fully up to
This is two minor bug fixes (aacraid, target) and a fix for a potential
exploit in the way sg handles teardown.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
David Disseldorp (1):
scsi: target: Fix truncated PR-
On Wed, 2018-07-04 at 04:51 +1000, James Morris wrote:
> On Tue, 3 Jul 2018, Jarkko Sakkinen wrote:
>
> > On Tue, Jul 03, 2018 at 08:26:55AM -0700, James Bottomley wrote:
> >
> > OK, I was not sure how that discussion went. I could add myself as
> > co-maintainer t
On Tue, 2018-07-03 at 18:24 +0300, Jarkko Sakkinen wrote:
[...]
>
> Reviewed-by: Jarkko Sakkinen
>
> Is James maintaining this now? Have not seen his feedback yet...
Hey, I thought we both were ...
However, it looks fine to me
Reviewed-by: James E.J. Bottomley
James
On Mon, 2018-07-02 at 14:18 -0700, Andrew Morton wrote:
> On Mon, 2 Jul 2018 12:34:00 -0700 Linus Torvalds dation.org> wrote:
>
> > On Sun, Jul 1, 2018 at 10:52 PM Waiman Long
> > wrote:
> > >
> > > A rogue application can potentially create a large number of
> > > negative
> > > dentries in th
On Wed, 2018-06-20 at 18:24 -0700, Tadeusz Struk wrote:
> On 06/20/2018 04:59 PM, James Bottomley wrote:
> > I'm slightly surprised by this statement. I thought IoT Node.js
> > runtimes (of which there are far too many, so I haven't looked at
> > all of them
On Tue, 2018-06-19 at 17:45 -0700, Tadeusz Struk wrote:
> On 06/19/2018 06:10 AM, Jarkko Sakkinen wrote:
> > On Tue, Jun 12, 2018 at 10:58:26AM -0700, Tadeusz Struk wrote:
> > > The TCG SAPI specification [1] defines a set of functions, which
> > > allows applications to use the TPM device in eithe
subtrees (using the -o mark option as root). Once
mounted, the subtree is mapped via the super block user namespace so
that the interior ids of the mounting user namespace are the ids
written to the filesystem.
Signed-off-by: James Bottomley
---
v3 - update to 4.14 (d_real changes)
v1 - based on
only allows root in the
host to use this, but it's not impossible to come up with a scheme for
marking trees that can safely be shift mounted by unprivileged user
namespaces.
James
---
James Bottomley (1):
shiftfs: uid/gid shifting bind mount
fs/Kconfig | 8 +
fs/Ma
Two driver fixes (zfcp and target core), one information leak in sg and
one build clean up.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Alexander Potapenko (1):
scsi: sg: allocate with __GFP_ZERO in sg_build_i
Two small driver fixes: aacraid to fix an unknown IU type on task
management functions which causes a firmware fault and vmw_pvscsi to
change a return code to retry the operation instead of causing an
immediate error
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/
On Tue, 2018-05-08 at 21:43 +, Sasha Levin via Ksummit-discuss
wrote:
> On Tue, May 08, 2018 at 01:59:18PM -0700, David Lang wrote:
> > On Tue, 8 May 2018, Sasha Levin wrote:
> >
> > > There's no one, for example, who picked up vanilla v4.16 and
> > > plans to keep using it for a year.
> >
>
On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote:
> If it's not necessary, fine. But we should still delete what is
> currently documented in stable_kernel_rules and was introduced in
> 8e9b9362266d, because it doesn't describe current practice.
It definitely doesn't seem to describe cur
On Thu, 2018-05-03 at 15:43 +, Sasha Levin via Ksummit-discuss
wrote:
> On Thu, May 03, 2018 at 08:27:48AM -0700, James Bottomley wrote:
[...]
> > It's also a sad fact that a lot of things which look like obvious
> > fixes actually turn out not to be so with later testing.
On Thu, 2018-05-03 at 15:06 +, Sasha Levin via Ksummit-discuss
wrote:
> On Thu, May 03, 2018 at 04:48:50PM +0200, Willy Tarreau wrote:
> > On Thu, May 03, 2018 at 07:33:04AM -0700, James Bottomley wrote:
> > > They're definitely for bug fixes, but there's a spect
On Thu, 2018-05-03 at 14:08 +0300, Jani Nikula wrote:
> On Tue, 01 May 2018, "Theodore Y. Ts'o" wrote:
> > Post -rc3 or -rc4, in my opinion bug fixes should wait until the
> > next
> > merge window before they get merged at all.
>
> What are -rc5 and later for then if not bug fixes? Baffled.
The
Three small bug fixes: an illegally overlapping memcmp in target code,
a potential infinite loop in isci under certain rare phy conditions and
an ATA queue depth (performance) correction for storvsc.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fix
On Thu, 2018-04-26 at 11:05 -0400, Mikulas Patocka wrote:
>
> On Thu, 26 Apr 2018, James Bottomley wrote:
[...]
> > Perhaps find out beforehand instead of insisting on an approach
> without
> > knowing. On openSUSE the grub config is built from the files in
> > /etc
On Thu, 2018-04-26 at 10:28 -0400, Mikulas Patocka wrote:
>
> On Thu, 26 Apr 2018, Michal Hocko wrote:
>
> > On Wed 25-04-18 18:42:57, Mikulas Patocka wrote:
> > >
> > >
> > > On Wed, 25 Apr 2018, James Bottomley wrote:
> > [...]
> >
On Wed, 2018-04-25 at 19:00 -0400, Mikulas Patocka wrote:
>
> On Wed, 25 Apr 2018, James Bottomley wrote:
>
> > > > Do we really need the new config option? This could just be
> > > > manually tunable via fault injection IIUC.
> > >
> > > We
On Wed, 2018-04-25 at 17:22 -0400, Mikulas Patocka wrote:
>
> On Wed, 25 Apr 2018, David Rientjes wrote:
>
> > On Wed, 25 Apr 2018, Mikulas Patocka wrote:
> >
> > > From: Mikulas Patocka
> > > Subject: [PATCH] fault-injection: introduce kvmalloc fallback
> > > options
> > >
> > > This patch in
8 bug fixes, one spelling update and one tracepoint addition. The most
serious is probably the mpt3sas write same fix because it means anyone
using these controllers sees errors when modern filesystems try to
issue discards (if the drive supports the WRITE SAME variant).
The patch is available he
On Wed, 2018-04-25 at 13:06 +0200, Greg KH wrote:
> On Wed, Apr 25, 2018 at 01:44:20PM +0300, Jarkko Sakkinen wrote:
> > "tpm: add retry logic" caused merge conflicts so I picked couple of
> > other fixes in order to get it apply cleanly.
>
> Are these only needed in 4.16.y? Nothing earlier?
The
On Fri, 2018-04-20 at 16:44 -0600, Anatoliy Glagolev wrote:
>
> > This patch isn't applyable because your mailer has changed all the
> > tabs to spaces.
> >
> > I also think there's no need to do it this way. I think what we
> > need is for fc_bsg_remove() to wait until the bsg queue is
> > dra
On Sat, 2018-04-21 at 19:43 +0200, Helge Deller wrote:
> On 20.04.2018 10:03, Christoph Hellwig wrote:
> > Switch to the generic noncoherent direct mapping implementation.
> >
> > Parisc previously had two different non-coherent dma ops
> > implementation that just different in the way coherent al
On Fri, 2018-04-20 at 10:03 +0200, Christoph Hellwig wrote:
> diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
> index 8d3a7b80ac42..4e87c35c22b7 100644
> --- a/arch/parisc/kernel/setup.c
> +++ b/arch/parisc/kernel/setup.c
> @@ -97,14 +97,12 @@ void __init dma_ops_init(void)
>
On Thu, 2018-04-19 at 15:10 -0700, Anatoliy Glagolev wrote:
> Updated: rebased on recent Linux, cc-ed maintainers per instructions
> in MAINTAINERS file
>
> From df939b80d02bf37b21efaaef8ede86cfd39b0cb8 Mon Sep 17 00:00:00
> 2001
> From: Anatoliy Glagolev
> Date: Thu, 19 Apr 2018 15:06:06 -0600
>
On Fri, 2018-04-20 at 10:03 +0100, Colin King wrote:
> From: Colin Ian King
>
> In the case when the phy_mask is bitwise anded with the
> phy_index bit is zero the continue statement currently jumps
> to the next iteration of the while loop and phy_index is
> never actually incremented, potential
On Tue, 2018-04-17 at 10:13 -0400, Sinan Kaya wrote:
> Hi James,
>
> >
> > Perhaps if you gave an example of the actual problem you're trying
> > to fix we could assess if it affects parisc.
>
> Let me clarify myself here. Maybe, there is a better solution.
>
> /* assign ownership
On Tue, 2018-04-17 at 11:16 -0400, Theodore Y. Ts'o wrote:
> On Tue, Apr 17, 2018 at 12:57:12PM +0100, James Bottomley wrote:
> >
> > You don't have to compromise the bootloader to influence this, you
> > merely have to trick it into providing the random number
On Tue, 2018-04-17 at 07:07 -0700, Matthew Wilcox wrote:
> On Tue, Apr 17, 2018 at 12:57:12PM +0100, James Bottomley wrote:
> > On Tue, 2018-04-17 at 04:47 -0700, Matthew Wilcox wrote:
> > > On Tue, Apr 17, 2018 at 10:13:34AM +0100, James Bottomley wrote:
> > > > On
On Tue, 2018-04-17 at 04:47 -0700, Matthew Wilcox wrote:
> On Tue, Apr 17, 2018 at 10:13:34AM +0100, James Bottomley wrote:
> > On Sat, 2018-04-14 at 17:41 -0700, Matthew Wilcox wrote:
> > > On Sat, Apr 14, 2018 at 06:44:19PM -0400, Theodore Y. Ts'o wrote:
> > > &g
On Mon, 2018-04-16 at 20:12 -0700, Kees Cook wrote:
> I still haven't figured this out, though... any have a moment to look
> at this?
Just to let you know you're not alone ... but I can't make any sense of
this either. The bfdq is the elevator_data, which is initialised when
the scheduler is att
On Tue, 2018-04-17 at 00:08 -0400, Sinan Kaya wrote:
> parisc architecture seems to be mapping readX() and readX_relaxed()
> APIs
> to __raw_readX() API.
>
> __raw_readX() API doesn't provide any kind of ordering guarantees.
> commit 032d59e1cde9 ("io: define stronger ordering for the default
> re
On Sat, 2018-04-14 at 17:41 -0700, Matthew Wilcox wrote:
> On Sat, Apr 14, 2018 at 06:44:19PM -0400, Theodore Y. Ts'o wrote:
> > What needs to happen is freelist should get randomized much later
> > in the boot sequence. Doing it later will require locking; I don't
> > know enough about the slab/s
This is a set of minor (and safe changes) that didn't make the initial
pull request plus some bug fixes. The status handling code is actually
a running regression from the previous merge window which had an
incomplete fix (now reverted) and most of the remaining bug fixes are
for problems older th
401 - 500 of 2290 matches
Mail list logo
