On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
> From: Andy Lutomirski <[email protected]>
>
> Fixes an easy DoS and possible information disclosure.
>
> This does nothing about the broken state of x32 auditing.
>
> eparis: If the admin has enabled auditd and has specifically loaded audit
> rules. This bug has been around since before git. Wow...
>
> Cc: [email protected]
> Signed-off-by: Andy Lutomirski <[email protected]>
> Signed-off-by: Eric Paris <[email protected]>
> ---
> kernel/auditsc.c | 27 ++++++++++++++++++---------
> 1 file changed, 18 insertions(+), 9 deletions(-)
Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
miss a later conversation about this?
thanks,
greg k-h
On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
> On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
>> From: Andy Lutomirski <[email protected]>
>>
>> Fixes an easy DoS and possible information disclosure.
>>
>> This does nothing about the broken state of x32 auditing.
>>
>> eparis: If the admin has enabled auditd and has specifically loaded audit
>> rules. This bug has been around since before git. Wow...
>>
>> Cc: [email protected]
>> Signed-off-by: Andy Lutomirski <[email protected]>
>> Signed-off-by: Eric Paris <[email protected]>
>> ---
>> kernel/auditsc.c | 27 ++++++++++++++++++---------
>> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
> miss a later conversation about this?
Hmm. It seems that it didn't make it into Linus' tree. Crap.
IMO we need some kind of real tracking system for issues reported to
security@. This shouldn't have been possible (and if I'd realized
that the patch got dropped, I wouldn't have publicly disclosed it).
For whoever applies this: it's CVE-2014-3917.
--Andy
On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
> > On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
> >> From: Andy Lutomirski <[email protected]>
> >>
> >> Fixes an easy DoS and possible information disclosure.
> >>
> >> This does nothing about the broken state of x32 auditing.
> >>
> >> eparis: If the admin has enabled auditd and has specifically loaded audit
> >> rules. This bug has been around since before git. Wow...
> >>
> >> Cc: [email protected]
> >> Signed-off-by: Andy Lutomirski <[email protected]>
> >> Signed-off-by: Eric Paris <[email protected]>
> >> ---
> >> kernel/auditsc.c | 27 ++++++++++++++++++---------
> >> 1 file changed, 18 insertions(+), 9 deletions(-)
> >
> > Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
> > miss a later conversation about this?
>
> Hmm. It seems that it didn't make it into Linus' tree. Crap.
>
> IMO we need some kind of real tracking system for issues reported to
> security@.
That seems to be my mbox at times :)
But yes, having something "real" might be good if the load gets higher,
right now it's so low that my "sweep pending security patches" task
usually catches anything pending, which is rare.
thanks,
greg k-h
On Mon, Jun 9, 2014 at 3:35 PM, Andy Lutomirski <[email protected]> wrote:
>
> Hmm. It seems that it didn't make it into Linus' tree. Crap.
I assume that if there is a maintainer who normally sends me stuff by
git, when I see patches in emails they are just informational
heads-ups about stuff that is being discussed or pending, and that
I'll see it later in a pull request. So I just ignore them unless I
have specific comments, since clearly the emailed patch is just
informational and/or for comments/acks from others.
The exception is unless it *VERY CLEARLY* says otherwise (as in
"Linus, can you please take this directly due to xyz").
Because why would somebody send me a patch series sometimes, and git
trees at other times? That would just be stupid.
Linus
On Mon, Jun 9, 2014 at 3:46 PM, Greg KH <[email protected]> wrote:
> On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote:
>> On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
>> > On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
>> >> From: Andy Lutomirski <[email protected]>
>> >>
>> >> Fixes an easy DoS and possible information disclosure.
>> >>
>> >> This does nothing about the broken state of x32 auditing.
>> >>
>> >> eparis: If the admin has enabled auditd and has specifically loaded audit
>> >> rules. This bug has been around since before git. Wow...
>> >>
>> >> Cc: [email protected]
>> >> Signed-off-by: Andy Lutomirski <[email protected]>
>> >> Signed-off-by: Eric Paris <[email protected]>
>> >> ---
>> >> kernel/auditsc.c | 27 ++++++++++++++++++---------
>> >> 1 file changed, 18 insertions(+), 9 deletions(-)
>> >
>> > Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
>> > miss a later conversation about this?
>>
>> Hmm. It seems that it didn't make it into Linus' tree. Crap.
>>
>> IMO we need some kind of real tracking system for issues reported to
>> security@.
>
> That seems to be my mbox at times :)
>
> But yes, having something "real" might be good if the load gets higher,
> right now it's so low that my "sweep pending security patches" task
> usually catches anything pending, which is rare.
>
There are currently at least two issues that I reported that are stuck
in limbo: this one and the (not-yet-public) vfs thing. And there's
the CVE-2014-0181 regression fix that almost got forgotten, but that
isn't really a security issue.
And I can't read your mbox :-/
--Andy
On Mon, Jun 9, 2014 at 3:53 PM, Linus Torvalds
<[email protected]> wrote:
> On Mon, Jun 9, 2014 at 3:35 PM, Andy Lutomirski <[email protected]> wrote:
>>
>> Hmm. It seems that it didn't make it into Linus' tree. Crap.
>
> I assume that if there is a maintainer who normally sends me stuff by
> git, when I see patches in emails they are just informational
> heads-ups about stuff that is being discussed or pending, and that
> I'll see it later in a pull request. So I just ignore them unless I
> have specific comments, since clearly the emailed patch is just
> informational and/or for comments/acks from others.
>
> The exception is unless it *VERY CLEARLY* says otherwise (as in
> "Linus, can you please take this directly due to xyz").
>
> Because why would somebody send me a patch series sometimes, and git
> trees at other times? That would just be stupid.
In this particular case, it's my patch, and I've never sent you a pull
request. I sort of assumed that [email protected] magically caused
acknowledged fixes to end up in your tree. I'm not sure what I'm
supposed to do here.
Maybe the confusion is because Eric resent the patch?
--Andy
On Mon, Jun 9, 2014 at 6:46 PM, Greg KH <[email protected]> wrote:
> On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote:
>> On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
>> > On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
>> >> From: Andy Lutomirski <[email protected]>
>> >>
>> >> Fixes an easy DoS and possible information disclosure.
>> >>
>> >> This does nothing about the broken state of x32 auditing.
>> >>
>> >> eparis: If the admin has enabled auditd and has specifically loaded audit
>> >> rules. This bug has been around since before git. Wow...
>> >>
>> >> Cc: [email protected]
>> >> Signed-off-by: Andy Lutomirski <[email protected]>
>> >> Signed-off-by: Eric Paris <[email protected]>
>> >> ---
>> >> kernel/auditsc.c | 27 ++++++++++++++++++---------
>> >> 1 file changed, 18 insertions(+), 9 deletions(-)
>> >
>> > Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
>> > miss a later conversation about this?
>>
>> Hmm. It seems that it didn't make it into Linus' tree. Crap.
>>
>> IMO we need some kind of real tracking system for issues reported to
>> security@.
>
> That seems to be my mbox at times :)
>
> But yes, having something "real" might be good if the load gets higher,
> right now it's so low that my "sweep pending security patches" task
> usually catches anything pending, which is rare.
How does one get added to the security@ alias? We've been carrying
this patch in Fedora for a bit now. I'd be happy to help track things
given we get distro security bug reports and such.
josh
On Mon, Jun 9, 2014 at 3:56 PM, Andy Lutomirski <[email protected]> wrote:
>
> In this particular case, it's my patch, and I've never sent you a pull
> request. I sort of assumed that [email protected] magically caused
> acknowledged fixes to end up in your tree. I'm not sure what I'm
> supposed to do here.
>
> Maybe the confusion is because Eric resent the patch?
So I saw the patch twice in email , but neither time did I get the
feeling that I should apply it. The first time Eric responded to it,
so the maintainer clearly knew about it and was reacting to it, so I
ignored it. The second time Eric resent it as email to various people
and lists, and I didn't react to it because I expected that was again
just for discussion.
So I'm not blaming you as much as Eric. If a maintainer expects me to
pick it up from the email (rather than his usual git pulls), I want
that maintainer to *say* so. Because otherwise, as mentioned, I expect
it to come through the maintainer tree as usual.
Linus
On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote:
> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH <[email protected]> wrote:
> > On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote:
> >> On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
> >> > On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
> >> >> From: Andy Lutomirski <[email protected]>
> >> >>
> >> >> Fixes an easy DoS and possible information disclosure.
> >> >>
> >> >> This does nothing about the broken state of x32 auditing.
> >> >>
> >> >> eparis: If the admin has enabled auditd and has specifically loaded audit
> >> >> rules. This bug has been around since before git. Wow...
> >> >>
> >> >> Cc: [email protected]
> >> >> Signed-off-by: Andy Lutomirski <[email protected]>
> >> >> Signed-off-by: Eric Paris <[email protected]>
> >> >> ---
> >> >> kernel/auditsc.c | 27 ++++++++++++++++++---------
> >> >> 1 file changed, 18 insertions(+), 9 deletions(-)
> >> >
> >> > Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
> >> > miss a later conversation about this?
> >>
> >> Hmm. It seems that it didn't make it into Linus' tree. Crap.
> >>
> >> IMO we need some kind of real tracking system for issues reported to
> >> security@.
> >
> > That seems to be my mbox at times :)
> >
> > But yes, having something "real" might be good if the load gets higher,
> > right now it's so low that my "sweep pending security patches" task
> > usually catches anything pending, which is rare.
>
> How does one get added to the security@ alias? We've been carrying
> this patch in Fedora for a bit now. I'd be happy to help track things
> given we get distro security bug reports and such.
Just ask on the security@ alias to be added and we can take it from
there.
thanks,
greg k-h
On Mon, Jun 09, 2014 at 03:55:20PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 9, 2014 at 3:46 PM, Greg KH <[email protected]> wrote:
> > On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote:
> >> On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
> >> > On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
> >> >> From: Andy Lutomirski <[email protected]>
> >> >>
> >> >> Fixes an easy DoS and possible information disclosure.
> >> >>
> >> >> This does nothing about the broken state of x32 auditing.
> >> >>
> >> >> eparis: If the admin has enabled auditd and has specifically loaded audit
> >> >> rules. This bug has been around since before git. Wow...
> >> >>
> >> >> Cc: [email protected]
> >> >> Signed-off-by: Andy Lutomirski <[email protected]>
> >> >> Signed-off-by: Eric Paris <[email protected]>
> >> >> ---
> >> >> kernel/auditsc.c | 27 ++++++++++++++++++---------
> >> >> 1 file changed, 18 insertions(+), 9 deletions(-)
> >> >
> >> > Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
> >> > miss a later conversation about this?
> >>
> >> Hmm. It seems that it didn't make it into Linus' tree. Crap.
> >>
> >> IMO we need some kind of real tracking system for issues reported to
> >> security@.
> >
> > That seems to be my mbox at times :)
> >
> > But yes, having something "real" might be good if the load gets higher,
> > right now it's so low that my "sweep pending security patches" task
> > usually catches anything pending, which is rare.
> >
>
> There are currently at least two issues that I reported that are stuck
> in limbo: this one and the (not-yet-public) vfs thing.
That was next on my list to poke people about...
> And there's the CVE-2014-0181 regression fix that almost got
> forgotten, but that isn't really a security issue.
What is that, where was that reported?
thanks,
greg k-h
On Mon, Jun 9, 2014 at 5:32 PM, Greg KH <[email protected]> wrote:
> On Mon, Jun 09, 2014 at 03:55:20PM -0700, Andy Lutomirski wrote:
>> On Mon, Jun 9, 2014 at 3:46 PM, Greg KH <[email protected]> wrote:
>> > On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote:
>> >> On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
>> >> > On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
>> >> >> From: Andy Lutomirski <[email protected]>
>> >> >>
>> >> >> Fixes an easy DoS and possible information disclosure.
>> >> >>
>> >> >> This does nothing about the broken state of x32 auditing.
>> >> >>
>> >> >> eparis: If the admin has enabled auditd and has specifically loaded audit
>> >> >> rules. This bug has been around since before git. Wow...
>> >> >>
>> >> >> Cc: [email protected]
>> >> >> Signed-off-by: Andy Lutomirski <[email protected]>
>> >> >> Signed-off-by: Eric Paris <[email protected]>
>> >> >> ---
>> >> >> kernel/auditsc.c | 27 ++++++++++++++++++---------
>> >> >> 1 file changed, 18 insertions(+), 9 deletions(-)
>> >> >
>> >> > Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
>> >> > miss a later conversation about this?
>> >>
>> >> Hmm. It seems that it didn't make it into Linus' tree. Crap.
>> >>
>> >> IMO we need some kind of real tracking system for issues reported to
>> >> security@.
>> >
>> > That seems to be my mbox at times :)
>> >
>> > But yes, having something "real" might be good if the load gets higher,
>> > right now it's so low that my "sweep pending security patches" task
>> > usually catches anything pending, which is rare.
>> >
>>
>> There are currently at least two issues that I reported that are stuck
>> in limbo: this one and the (not-yet-public) vfs thing.
>
> That was next on my list to poke people about...
>
>> And there's the CVE-2014-0181 regression fix that almost got
>> forgotten, but that isn't really a security issue.
>
> What is that, where was that reported?
commit 2d7a85f4b06e9c27ff629f07a524c48074f07f81
Author: Eric W. Biederman <[email protected]>
Date: Fri May 30 11:04:00 2014 -0700
netlink: Only check file credentials for implicit destinations
The security issue got fixed quickly, but the fix turned out to be problematic.
--Andy
On Mon, Jun 09, 2014 at 05:30:19PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 9, 2014 at 5:32 PM, Greg KH <[email protected]> wrote:
> > On Mon, Jun 09, 2014 at 03:55:20PM -0700, Andy Lutomirski wrote:
> >> On Mon, Jun 9, 2014 at 3:46 PM, Greg KH <[email protected]> wrote:
> >> > On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote:
> >> >> On Mon, Jun 9, 2014 at 3:30 PM, Greg KH <[email protected]> wrote:
> >> >> > On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote:
> >> >> >> From: Andy Lutomirski <[email protected]>
> >> >> >>
> >> >> >> Fixes an easy DoS and possible information disclosure.
> >> >> >>
> >> >> >> This does nothing about the broken state of x32 auditing.
> >> >> >>
> >> >> >> eparis: If the admin has enabled auditd and has specifically loaded audit
> >> >> >> rules. This bug has been around since before git. Wow...
> >> >> >>
> >> >> >> Cc: [email protected]
> >> >> >> Signed-off-by: Andy Lutomirski <[email protected]>
> >> >> >> Signed-off-by: Eric Paris <[email protected]>
> >> >> >> ---
> >> >> >> kernel/auditsc.c | 27 ++++++++++++++++++---------
> >> >> >> 1 file changed, 18 insertions(+), 9 deletions(-)
> >> >> >
> >> >> > Did this patch get dropped somewhere? Isn't it a valid bugfix, or did I
> >> >> > miss a later conversation about this?
> >> >>
> >> >> Hmm. It seems that it didn't make it into Linus' tree. Crap.
> >> >>
> >> >> IMO we need some kind of real tracking system for issues reported to
> >> >> security@.
> >> >
> >> > That seems to be my mbox at times :)
> >> >
> >> > But yes, having something "real" might be good if the load gets higher,
> >> > right now it's so low that my "sweep pending security patches" task
> >> > usually catches anything pending, which is rare.
> >> >
> >>
> >> There are currently at least two issues that I reported that are stuck
> >> in limbo: this one and the (not-yet-public) vfs thing.
> >
> > That was next on my list to poke people about...
> >
> >> And there's the CVE-2014-0181 regression fix that almost got
> >> forgotten, but that isn't really a security issue.
> >
> > What is that, where was that reported?
>
> commit 2d7a85f4b06e9c27ff629f07a524c48074f07f81
> Author: Eric W. Biederman <[email protected]>
> Date: Fri May 30 11:04:00 2014 -0700
>
> netlink: Only check file credentials for implicit destinations
>
>
> The security issue got fixed quickly, but the fix turned out to be problematic.
Ah, thanks, I rely on Dave to send me networking stable patches, I'm
sure he's on this...
[cc list trimmed, security@ added]
On Mon, Jun 9, 2014 at 5:31 PM, Greg KH <[email protected]> wrote:
> On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote:
>> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH <[email protected]> wrote:
>> >
>> > But yes, having something "real" might be good if the load gets higher,
>> > right now it's so low that my "sweep pending security patches" task
>> > usually catches anything pending, which is rare.
>>
>> How does one get added to the security@ alias? We've been carrying
>> this patch in Fedora for a bit now. I'd be happy to help track things
>> given we get distro security bug reports and such.
>
> Just ask on the security@ alias to be added and we can take it from
> there.
>
Would it make sense for there to be someone on the security list who
can assign CVE numbers?
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On Mon, Jun 09, 2014 at 05:51:37PM -0700, Andy Lutomirski wrote:
> [cc list trimmed, security@ added]
>
> On Mon, Jun 9, 2014 at 5:31 PM, Greg KH <[email protected]> wrote:
> > On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote:
> >> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH <[email protected]> wrote:
> >> >
> >> > But yes, having something "real" might be good if the load gets higher,
> >> > right now it's so low that my "sweep pending security patches" task
> >> > usually catches anything pending, which is rare.
> >>
> >> How does one get added to the security@ alias? We've been carrying
> >> this patch in Fedora for a bit now. I'd be happy to help track things
> >> given we get distro security bug reports and such.
> >
> > Just ask on the security@ alias to be added and we can take it from
> > there.
> >
>
> Would it make sense for there to be someone on the security list who
> can assign CVE numbers?
I'm pretty sure we have that already.
thanks,
greg k-h
On Mon, Jun 9, 2014 at 7:57 PM, Greg KH <[email protected]> wrote:
> On Mon, Jun 09, 2014 at 05:51:37PM -0700, Andy Lutomirski wrote:
>> [cc list trimmed, security@ added]
>>
>> On Mon, Jun 9, 2014 at 5:31 PM, Greg KH <[email protected]> wrote:
>> > On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote:
>> >> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH <[email protected]> wrote:
>> >> >
>> >> > But yes, having something "real" might be good if the load gets higher,
>> >> > right now it's so low that my "sweep pending security patches" task
>> >> > usually catches anything pending, which is rare.
>> >>
>> >> How does one get added to the security@ alias? We've been carrying
>> >> this patch in Fedora for a bit now. I'd be happy to help track things
>> >> given we get distro security bug reports and such.
>> >
>> > Just ask on the security@ alias to be added and we can take it from
>> > there.
>> >
>>
>> Would it make sense for there to be someone on the security list who
>> can assign CVE numbers?
>
> I'm pretty sure we have that already.
Let me rephrase the question:
Would it make sense for someone on the security list to assign CVE numbers?
--Andy
On Mon, Jun 09, 2014 at 09:04:16PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 9, 2014 at 7:57 PM, Greg KH <[email protected]> wrote:
> > On Mon, Jun 09, 2014 at 05:51:37PM -0700, Andy Lutomirski wrote:
> >> [cc list trimmed, security@ added]
> >>
> >> On Mon, Jun 9, 2014 at 5:31 PM, Greg KH <[email protected]> wrote:
> >> > On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote:
> >> >> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH <[email protected]> wrote:
> >> >> >
> >> >> > But yes, having something "real" might be good if the load gets higher,
> >> >> > right now it's so low that my "sweep pending security patches" task
> >> >> > usually catches anything pending, which is rare.
> >> >>
> >> >> How does one get added to the security@ alias? We've been carrying
> >> >> this patch in Fedora for a bit now. I'd be happy to help track things
> >> >> given we get distro security bug reports and such.
> >> >
> >> > Just ask on the security@ alias to be added and we can take it from
> >> > there.
> >> >
> >>
> >> Would it make sense for there to be someone on the security list who
> >> can assign CVE numbers?
> >
> > I'm pretty sure we have that already.
>
> Let me rephrase the question:
>
> Would it make sense for someone on the security list to assign CVE numbers?
If we cared about CVE numbers, maybe :)
Seriously, there are people on the security alias that can get CVE
numbers assigned if needed, so that should not be an issue. It's
happened in the past from what I can recall.
thanks,
greg k-h
On Mon, 2014-06-09 at 16:36 -0700, Linus Torvalds wrote:
> On Mon, Jun 9, 2014 at 3:56 PM, Andy Lutomirski <[email protected]> wrote:
> >
> > In this particular case, it's my patch, and I've never sent you a pull
> > request. I sort of assumed that [email protected] magically caused
> > acknowledged fixes to end up in your tree. I'm not sure what I'm
> > supposed to do here.
> >
> > Maybe the confusion is because Eric resent the patch?
>
> So I saw the patch twice in email , but neither time did I get the
> feeling that I should apply it. The first time Eric responded to it,
> so the maintainer clearly knew about it and was reacting to it, so I
> ignored it. The second time Eric resent it as email to various people
> and lists, and I didn't react to it because I expected that was again
> just for discussion.
>
> So I'm not blaming you as much as Eric.
No, it's good to blame me. I was trying to deal with it as fast as I
could since I was already trying to ignore my computer before I got
married last weekend and took the last week off. I realized when I got
back yesterday you hadn't picked it up and it was on my list of things
to try to handle today. I think both 1 and 2 are good to be applied to
your tree. Although only #1 is really an absolutely critical issue.
> If a maintainer expects me to
> pick it up from the email (rather than his usual git pulls), I want
> that maintainer to *say* so. Because otherwise, as mentioned, I expect
> it to come through the maintainer tree as usual.
>
> Linus
On Tue, Jun 10, 2014 at 5:50 AM, Eric Paris <[email protected]> wrote:
>
> No, it's good to blame me. I was trying to deal with it as fast as I
> could since I was already trying to ignore my computer before I got
> married last weekend and took the last week off. I realized when I got
> back yesterday you hadn't picked it up and it was on my list of things
> to try to handle today. I think both 1 and 2 are good to be applied to
> your tree. Although only #1 is really an absolutely critical issue.
Ok, I'll take your patch-series rather than the recent pull from Andy,
and pick up #2 that way too.
I'll just take them from emails - it's not like I have to wait for a
pull from you. It's just that I don't want to take them from emails
_and_ then get them in a pull from you, which is why I tend to want to
get explicit "please apply these directly" notification.
Linus
On Tue, Jun 10, 2014 at 8:42 AM, Linus Torvalds
<[email protected]> wrote:
>
> Ok, I'll take your patch-series rather than the recent pull from Andy,
> and pick up #2 that way too.
Hmm. In fact, #2 doesn't apply cleanly. It's trivial to fix up, but
rather than do that, the reject made me go "I'll just forward this to
Peter Anvin" instead, so that he's aware of the x32 issue.
Linus