On Sun, Oct 28, 2018 at 7:46 PM David Miller wrote:
>
> Please pull, thanks a lot!
Pulled,
Linus
On Fri, May 11, 2018 at 5:10 PM David Miller wrote:
> I guess this is my reward for trying to break the monotony of
> pull requests :-)
I actually went back and checked a few older pull requests to see if this
had been going on for a while and I just hadn't noticed.
It
From: Linus Torvalds
Date: Fri, 11 May 2018 14:25:59 -0700
> David, is there something you want to tell us?
>
> Drugs are bad, m'kay..
I guess this is my reward for trying to break the monotony of
pull requests :-)
David, is there something you want to tell us?
Drugs are bad, m'kay..
Linus
On Fri, May 11, 2018 at 2:00 PM David Miller wrote:
> "from Kevin Easton", "Thanks to Bhadram Varka", "courtesy of Gustavo A.
> R. Silva", "To Eric Dumazet we are most grateful for
Sorry, this is a dup of the bug fix pull request from last week.
I'll send you the right one.
From: Daniel Borkmann
Date: Wed, 15 Nov 2017 23:15:20 +0100
> On 11/15/2017 09:19 PM, Linus Torvalds wrote:
>> On Wed, Nov 15, 2017 at 3:33 AM, David Miller wrote:
>>>
>>> Highlights:
>>
>> Lowlights:
>>
>> 1) it duplicated a commit from the hrtimer
On 11/15/2017 09:19 PM, Linus Torvalds wrote:
> On Wed, Nov 15, 2017 at 3:33 AM, David Miller wrote:
>>
>> Highlights:
>
> Lowlights:
>
> 1) it duplicated a commit from the hrtimer tree, which had been
> cleaned up and rewritten, but then merging the second copy of the
>
On Wed, Nov 15, 2017 at 3:33 AM, David Miller wrote:
>
> Highlights:
Lowlights:
1) it duplicated a commit from the hrtimer tree, which had been
cleaned up and rewritten, but then merging the second copy of the
commit re-introduced the bad code that had been cleaned up.
On Wed, Sep 6, 2017 at 10:40 PM, Luca Coelho wrote:
>
> This patch is not very important (unless you really like blinking lights
> -- maybe I'll change my mind when the holidays approach :P). so it is
> fine if you just want to revert it for now.
>
> In any case, I'll send a patch
On Thu, 2017-09-07 at 05:04 +, Coelho, Luciano wrote:
> On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote:
> > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
> > wrote:
> > >
> > > This seems to be a problem with backwards-compatibility with FW version
> > >
On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote:
> On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
> wrote:
> >
> > This seems to be a problem with backwards-compatibility with FW version
> > 27. We are now in version 31[1] and upgrading will probably fix that.
On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
wrote:
>
> This seems to be a problem with backwards-compatibility with FW version
> 27. We are now in version 31[1] and upgrading will probably fix that.
I can confirm that fw version 31 works.
> But obviously the
On Wed, 2017-09-06 at 16:27 -0700, Linus Torvalds wrote:
> This pull request completely breaks Intel wireless for me.
>
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
>
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
>
> The
On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds
wrote:
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
>
> iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm
And when I said
From: Linus Torvalds
Date: Wed, 6 Sep 2017 16:27:15 -0700
> This pull request completely breaks Intel wireless for me.
>
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
>
> That remains a very standard Intel machine with absolutely zero
This pull request completely breaks Intel wireless for me.
This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
That remains a very standard Intel machine with absolutely zero odd
things going on.
The firmware is iwlwifi-8000C-28.ucode from
(Adding linux-wireless)
Pavel Machek writes:
> On Thu 2017-08-31 07:44:58, Kalle Valo wrote:
>> David Miller writes:
>>
>> > From: Kalle Valo
>> > Date: Wed, 30 Aug 2017 20:31:31 +0300
>> >
>> >> AFAICS the bug was introduced by
On Thu 2017-08-31 07:44:58, Kalle Valo wrote:
> David Miller writes:
>
> > From: Kalle Valo
> > Date: Wed, 30 Aug 2017 20:31:31 +0300
> >
> >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug
> >> has been there for 7 years so
David Miller writes:
> From: Kalle Valo
> Date: Wed, 30 Aug 2017 20:31:31 +0300
>
>> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug
>> has been there for 7 years so waiting for a few more weeks should not
>> hurt.
>
> As a
From: Kalle Valo
Date: Wed, 30 Aug 2017 20:31:31 +0300
> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug
> has been there for 7 years so waiting for a few more weeks should not
> hurt.
As a maintainer you have a right to handle bug fixing in that
David Miller writes:
> From: Kalle Valo
> Date: Wed, 30 Aug 2017 17:45:31 +0300
>
>> Pavel Machek writes:
>>
>>> Could we get this one in?
>>>
>>> wl1251 misses a spin_lock_init().
>>>
>>>
From: Kalle Valo
Date: Wed, 30 Aug 2017 17:45:31 +0300
> Pavel Machek writes:
>
>> Could we get this one in?
>>
>> wl1251 misses a spin_lock_init().
>>
>> https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html
>>
>> It seems pretty trivial, yet
Pavel Machek writes:
> Could we get this one in?
>
> wl1251 misses a spin_lock_init().
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html
>
> It seems pretty trivial, yet getting the backtraces is not nice.
It's in wireless-drivers-next and will be in 4.14-rc1:
Hi!
Could we get this one in?
wl1251 misses a spin_lock_init().
https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html
It seems pretty trivial, yet getting the backtraces is not nice.
Thanks,
Pavel
--
(english)
From: Linus Torvalds
Date: Tue, 15 Aug 2017 19:21:16 -0700
> On Tue, Aug 15, 2017 at 5:52 PM, David Miller wrote:
>>
>> dingtianhong (4):
>> PCI: Disable PCIe Relaxed Ordering if unsupported
>> PCI: Disable Relaxed Ordering for
On Tue, Aug 15, 2017 at 5:52 PM, David Miller wrote:
>
> dingtianhong (4):
> PCI: Disable PCIe Relaxed Ordering if unsupported
> PCI: Disable Relaxed Ordering for some Intel processors
> PCI: Disable Relaxed Ordering Attributes for AMD A1100
> PCI: fix
On Tue, Jul 11, 2017 at 01:31:14PM -0700, David Miller wrote:
>
> Acked-by: David S. Miller
>
> Looks good, is this going via my tree or your's?
I'll push it along. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
From: Herbert Xu
Date: Mon, 10 Jul 2017 22:00:48 +0800
> crypto: af_alg - Avoid sock_graft call warning
>
> The newly added sock_graft warning triggers in af_alg_accept.
> It's harmless as we're essentially doing sock->sk = sock->sk.
>
> The sock_graft call is
On Mon, Jul 10, 2017 at 08:10:02AM -0400, Sowmini Varadhan wrote:
>
> The reason that the WARN_ON is triggered is that af_alg_accept() calls
> sock_init_data() which does
>
>2636 if (sock) {
> :
>2639 sock->sk= sk;
Oh yes. This started out with
On (07/10/17 18:05), Herbert Xu wrote:
>
> Hmm, I can't see the problem in af_alg_accept. The struct socket
> comes directly from sys_accept() which creates it using sock_alloc.
>
> So the only thing I can think of is that the memory returned by
> sock_alloc is not zeroed and therefore the
On Sun, Jul 09, 2017 at 09:40:43PM +0100, David Miller wrote:
>
> > It look like PF_ALG sets up a ->sk in alg_create() (but this
> > would get over-written in alg_accept()?)
No it does not. The struct socket comes from sys_accept() and
AFAICS it doesn't carry a struck sock with it.
> > Cc'ing
From: Sowmini Varadhan
Date: Sun, 9 Jul 2017 15:11:31 -0400
> On (07/09/17 11:49), Linus Torvalds wrote:
>>
>> On Sat, Jul 8, 2017 at 3:36 AM, David Miller wrote:
>> >
>> > 8) Fix socket leak on accept() in RDS, from Sowmini Varadhan. Also
>>
On (07/09/17 11:49), Linus Torvalds wrote:
>
> On Sat, Jul 8, 2017 at 3:36 AM, David Miller wrote:
> >
> > 8) Fix socket leak on accept() in RDS, from Sowmini Varadhan. Also
> >add a WARN_ON() to sock_graft() so other protocol stacks don't trip
> >over this as well.
On Sat, Jul 8, 2017 at 3:36 AM, David Miller wrote:
>
> 8) Fix socket leak on accept() in RDS, from Sowmini Varadhan. Also
>add a WARN_ON() to sock_graft() so other protocol stacks don't trip
>over this as well.
Hmm. This one triggers for me on both my desktop and
Hi Jason,
On Wed, Feb 22, 2017 at 5:31 AM, David Miller wrote:
> 3) Introduce SIPHASH and it's usage for secure sequence numbers and
>syncookies. From Jason A. Donenfeld.
> Jason A. Donenfeld (4):
> siphash: add cryptographically secure PRF
> siphash:
From: David Miller
Date: Wed, 15 Feb 2017 22:26:56 -0500 (EST)
> From: Linus Torvalds
> Date: Wed, 15 Feb 2017 18:01:24 -0800
>
>> So David, you really need to convince me that this pull is truly
>> required.
>
> I'll revert those changes,
From: Linus Torvalds
Date: Wed, 15 Feb 2017 18:01:24 -0800
> So David, you really need to convince me that this pull is truly
> required.
I'll revert those changes, give me a second.
On Wed, Feb 15, 2017 at 5:31 PM, David Miller wrote:
>
> 3) More gracefully handle rhashtable insertion errors when vmalloc is
>not possible, from Herbert Xu.
Ugh.
So I pulled this, but when I look at his code, I'm really not sure
that I should have, and I haven't
Thanks. Pulled, going through my usual allmodconfig test-build before
being pushed out,
Linus
On Wed, Jan 11, 2017 at 7:22 AM, David Miller wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
David Miller writes:
> From: Linus Torvalds
> Date: Mon, 9 Jan 2017 12:08:02 -0800
>
>> On Sun, Jan 8, 2017 at 7:38 PM, David Miller wrote:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>>
>> Hmm.
Linus Torvalds writes:
> On Sun, Jan 8, 2017 at 7:38 PM, David Miller wrote:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>
> Hmm. This still doesn't contain the rtlwifi oops fix that was posted
> back before christmas.
>
>
From: Linus Torvalds
Date: Mon, 9 Jan 2017 12:08:02 -0800
> On Sun, Jan 8, 2017 at 7:38 PM, David Miller wrote:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>
> Hmm. This still doesn't contain the rtlwifi oops fix that was
On Sun, Jan 8, 2017 at 7:38 PM, David Miller wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Hmm. This still doesn't contain the rtlwifi oops fix that was posted
back before christmas.
Kalle said it was applied to the wireless-drivers tree as commit
Hi Dave,
On Wed, 05 Oct 2016 22:56:12 -0400 (EDT) David Miller
wrote:
>
> Yes, this is where the change got lost.
No worries.
> I have all of the fixups queued up in my net tree and will send in a pull
> request later.
Thanks.
--
Cheers,
Stephen Rothwell
From: Stephen Rothwell
Date: Thu, 6 Oct 2016 13:51:52 +1100
> On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds
> wrote:
>>
>> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell
>> wrote:
>> >
>> > Except that commit
Hi Linus,
On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds
wrote:
>
> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell
> wrote:
> >
> > Except that commit effectively moved that function from
> > net/netfilter/nf_tables_netdev.c to
> >
On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell wrote:
>
> Except that commit effectively moved that function from
> net/netfilter/nf_tables_netdev.c to
> include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> ("netfilter: nf_tables_netdev: remove redundant
Hi Linus,
On Wed, 5 Oct 2016 15:37:17 -0700 Linus Torvalds
wrote:
>
> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell
> wrote:
> >
> > I have been carrying the following merge fix patch (for the merge of
> > the net-next tree with Linus'
From: Pablo Neira Ayuso
Date: Thu, 6 Oct 2016 02:09:45 +0200
> On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote:
>> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell
>> wrote:
>> >
>> > I have been carrying the following merge fix patch
On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote:
> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell
> wrote:
> >
> > I have been carrying the following merge fix patch (for the merge of
> > the net-next tree with Linus' tree) for a while now which seems to
On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell wrote:
>
> I have been carrying the following merge fix patch (for the merge of
> the net-next tree with Linus' tree) for a while now which seems to have
> got missed:
Ugh. It doesn't seem to be a merge error, because that
Hi Linus, Dave,
On Wed, 05 Oct 2016 01:44:37 -0400 (EDT) David Miller
wrote:
>
I have been carrying the following merge fix patch (for the merge of
the net-next tree with Linus' tree) for a while now which seems to have
got missed:
From: Stephen Rothwell
On 5/19/16, Reinoud Koornstra wrote:
> On Thu, May 19, 2016 at 2:20 AM, Reinoud Koornstra
> wrote:
>> On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds
>> wrote:
>>> On Wed, May 18, 2016 at 11:45 AM, Linus
On Thu, May 19, 2016 at 2:20 AM, Reinoud Koornstra
wrote:
> On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds
> wrote:
>> On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
>> wrote:
>>>
>>> From what I can
On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds
wrote:
> On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
> wrote:
>>
>> From what I can tell, there's a merge bug in commit 909b27f70643,
>> where David seems to have lost some of the
From: Linus Torvalds
Date: Wed, 18 May 2016 11:45:06 -0700
> David, do you happen to recall that merge conflict? I think you must
> have removed that "skb_info" variable declaration and initialization
> manually (due to the "unused variable" warning, which in turn
Linus Torvalds writes:
> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote:
>>
>> It would be best if you could send a patch either directly to Dave or
>> Linus to resolve this quickly.
>
> I'm committing my patch myself right now, since
On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo
> wrote:
> >
> >
> > It would be best if you could send a patch either directly to Dave
> > or
> > Linus to resolve this quickly.
> I'm committing my patch myself right
On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote:
>
> It would be best if you could send a patch either directly to Dave or
> Linus to resolve this quickly.
I'm committing my patch myself right now, since this bug makes my
laptop useless, and I will take credit for
"Coelho, Luciano" writes:
> Kalle, David, what is the status with the fix that is on the way via
> your trees?
It would be best if you could send a patch either directly to Dave or
Linus to resolve this quickly.
--
Kalle Valo
On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
wrote:
>
> From what I can tell, there's a merge bug in commit 909b27f70643,
> where David seems to have lost some of the changes to
> iwl_mvm_set_tx_cmd().
>
> I do not know if that's the reason for the problem I
On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
> wrote:
> >
> >
> > I can confirm that 4.6 contains the same bug. And reverting the
> > patch
> > I mentioned does solve the problem...
> >
> > The same patch
On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
wrote:
>
> I can confirm that 4.6 contains the same bug. And reverting the patch
> I mentioned does solve the problem...
>
> The same patch works fine in our internal tree. I'll have to figure
> out together with
On Wed, 2016-05-18 at 06:51 -0600, Reinoud Koornstra wrote:
> On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano
> wrote:
> >
> > On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
> > >
> > > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
> > >
On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano
wrote:
> On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
>> On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
>> wrote:
>> >
>> > Hi Emmanuel, Linus,
>> >
>> >
>> > On Wed, 2016-05-18
On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
> On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
> wrote:
> >
> > Hi Emmanuel, Linus,
> >
> >
> > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> > >
> > > On Wed, May 18, 2016 at 4:00 AM,
On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
wrote:
> Hi Emmanuel, Linus,
>
>
> On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
>> On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>> wrote:
>> >
>> > On Tue, May 17, 2016 at
Hi Emmanuel, Linus,
On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
> wrote:
> >
> > On Tue, May 17, 2016 at 12:11 PM, David Miller > > wrote:
> > >
> > >
> > > Highlights:
> >
On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
wrote:
> On Tue, May 17, 2016 at 12:11 PM, David Miller wrote:
>>
>> Highlights:
>
> Lowlights:
>
> 1) the iwlwifi driver seems to be broken
>
> My laptop that uses the intel 7680 iwlwifi module
On Tue, May 17, 2016 at 12:11 PM, David Miller wrote:
>
> Highlights:
Lowlights:
1) the iwlwifi driver seems to be broken
My laptop that uses the intel 7680 iwlwifi module no longer connects
to the network. It fails with a "Microcode SW error detected." and
spews out
On 3/19/2016 6:42 AM, David Miller wrote:
There is a merge conflict against the RDMA tree pull wrt the mlx4 driver,
which I don't know how to resolve.
Can you please point on the conflict ? is it still open that needs our
input ?
On Mon, Nov 09 2015, Hannes Frederic Sowa wrote:
> Hi,
>
> On Wed, Oct 28, 2015, at 15:27, Rasmus Villemoes wrote:
>>
>> I agree - proper overflow checking can be really hard. Quick, assuming a
>> and b have the same unsigned integer type, is 'a+b>
Hello,
Ingo Molnar writes:
> * Linus Torvalds wrote:
>
>> Does anybody have any particular other "uhhuh, overflow in multiplication"
>> issues in mind? Because the interface for a saturating multiplication (or
>> addition, for that matter)
Hello,
Ingo Molnar writes:
> * Linus Torvalds wrote:
>
>> Does anybody have any particular other "uhhuh, overflow in multiplication"
>> issues in mind? Because the interface for a saturating multiplication (or
>> addition, for that matter)
* Linus Torvalds wrote:
> Does anybody have any particular other "uhhuh, overflow in multiplication"
> issues in mind? Because the interface for a saturating multiplication (or
> addition, for that matter) would actually be much easier. And would be
> trivial
Hi,
On Wed, Oct 28, 2015, at 15:27, Rasmus Villemoes wrote:
> On Wed, Oct 28 2015, Hannes Frederic Sowa
> wrote:
>
> > Hi Linus,
> >
> > On Wed, Oct 28, 2015, at 10:39, Linus Torvalds wrote:
> >> Get rid of it. And I don't *ever* want to see that shit again.
> >
> >
On Fri, Nov 6, 2015 at 7:27 AM, David Laight wrote:
>> From: Linus Torvalds
>> Sent: 03 November 2015 20:45
>> On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds
>> wrote:
>> > result = add_overflow(
>> > mul_overflow(sec,
> From: Linus Torvalds
> Sent: 03 November 2015 20:45
> On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds
> wrote:
> > result = add_overflow(
> > mul_overflow(sec, SEC_CONVERSION, ),
> > mul_overflow(nsec, NSEC_CONVERSION, ),
> > );
> >
>
Hello,
On Tue, Nov 3, 2015, at 03:38, Linus Torvalds wrote:
> On Mon, Nov 2, 2015 at 5:58 PM, Andy Lutomirski
> wrote:
> >
> > Based in part on an old patch by Sasha, what if we relied on CSE:
> >
> > if (mul_would_overflow(size, n))
> > return NULL;
> >
On Tue, Nov 3, 2015 at 4:53 AM, Hannes Frederic Sowa
wrote:
>
> And furthermore we don't actually have to rely on CSE if we want to, our
> overflow checks could look much more simpler as in "ordinary" C code
> because we tell the compiler that signed overflow is
On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds
wrote:
> result = add_overflow(
> mul_overflow(sec, SEC_CONVERSION, ),
> mul_overflow(nsec, NSEC_CONVERSION, ),
> );
>
> return overflow ? MAX_JIFFIES : result;
Thinking more about
On 10/28/2015 02:39 AM, Linus Torvalds wrote:
I'm sorry, but we don't add idiotic new interfaces like this for
idiotic new code like that.
As one of the people who encouraged gcc to add this interface, I'll
speak up in its favor:
Getting overflow checking right in more complicated cases is
On Mon, Nov 2, 2015 at 1:16 PM, Linus Torvalds
wrote:
> On Mon, Nov 2, 2015 at 12:34 PM, Andy Lutomirski wrote:
>>
>> Getting overflow checking right in more complicated cases is a PITA.
>
> No it is not. Not for unsigned values.
Just to clarify.
Hello,
On Mon, Nov 2, 2015, at 22:30, Andy Lutomirski wrote:
> On Mon, Nov 2, 2015 at 1:19 PM, Linus Torvalds
> wrote:
> > On Mon, Nov 2, 2015 at 1:16 PM, Linus Torvalds
> > wrote:
> >> On Mon, Nov 2, 2015 at 12:34 PM, Andy
On Mon, Nov 2, 2015 at 1:19 PM, Linus Torvalds
wrote:
> On Mon, Nov 2, 2015 at 1:16 PM, Linus Torvalds
> wrote:
>> On Mon, Nov 2, 2015 at 12:34 PM, Andy Lutomirski wrote:
>>>
>>> Getting overflow checking right in
On Mon, Nov 2, 2015 at 12:34 PM, Andy Lutomirski wrote:
> On 10/28/2015 02:39 AM, Linus Torvalds wrote:
>>
>> I'm sorry, but we don't add idiotic new interfaces like this for
>> idiotic new code like that.
>
>
> As one of the people who encouraged gcc to add this interface, I'll
On Mon, Nov 2, 2015 at 2:14 PM, Hannes Frederic Sowa
wrote:
>
> overflow_usub was part of a larger header I already prepared to offer
> support for *all* overflow_* checking builtins. While fixing this IPv6
> bug I thought I could hopefully introduce this interface
On Mon, 2015-11-02 at 13:30 -0800, Andy Lutomirski wrote:
>
> I'll stop making inane arguments if you stop bashing arguments I
> didn't make. :) I said the helpers were useful for multiplication (by
> which I meant both signed and unsigned) and, to a lesser extent, for
> signed addition and
On Mon, Nov 2, 2015 at 4:56 PM, Benjamin Herrenschmidt
wrote:
>
> Also how much of the problem is simply that the function signature
> (naming and choice of arguments) just plain sucks ?
Some of that is pretty much inevitable.
C really has no good way to return
On Mon, Nov 2, 2015 at 5:54 PM, Linus Torvalds
wrote:
>
> The biggest problem - and where the compiler could actually help us -
> tends to be multiplication overflows. We have several (not *many*, but
> certainly more than just a couple) cases where we simply check
On Mon, Nov 2, 2015 at 5:58 PM, Andy Lutomirski wrote:
>
> Based in part on an old patch by Sasha, what if we relied on CSE:
>
> if (mul_would_overflow(size, n))
> return NULL;
> do_something_with(size * n);
I suspect we wouldn't even have to rely on CSE. Are these things
From: David Miller
Date: Thu, 29 Oct 2015 08:19:41 -0700 (PDT)
> This is the same as the previous pull request, with the ipv6 overflow
> fix redone. The merge conflict is therefore gone too.
...
> Please pull, thanks a lot.
>
> The following changes since commit
From: Linus Torvalds
Date: Wed, 28 Oct 2015 18:39:56 +0900
> Get rid of it. And I don't *ever* want to see that shit again.
No problem, I'll revert it all.
I asked Hannes to repost his patches to linux-kernel hoping someone
would review and say it stunk or not,
On Wed, Oct 28 2015, Hannes Frederic Sowa wrote:
> Hi Linus,
>
> On Wed, Oct 28, 2015, at 10:39, Linus Torvalds wrote:
>> Get rid of it. And I don't *ever* want to see that shit again.
>
> I don't want to give up on that this easily:
>
> In future I would like to see
On Wed, Oct 28, 2015 at 3:32 PM, David Miller wrote:
>
> This may look a bit scary this late in the release cycle, but as is typically
> the case it's predominantly small driver fixes all over the place.
Christ people. This is just sh*t.
The conflict I get is due to stupid
Hi Linus,
On Wed, Oct 28, 2015, at 10:39, Linus Torvalds wrote:
> On Wed, Oct 28, 2015 at 3:32 PM, David Miller
> wrote:
> >
> > This may look a bit scary this late in the release cycle, but as is
> > typically
> > the case it's predominantly small driver fixes all over the
On Sep 8 22:16, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 8, 2015 at 10:14 PM, Konrad Rzeszutek Wilk
> wrote:
> >
> > (Removed Linus and Andrew from the To, added Corinna ..)
>
> and resending again without HTML (sorry, thought I had HTML-emails
> disabled by default)
> >
>
On Tue, Sep 8, 2015 at 10:14 PM, Konrad Rzeszutek Wilk
wrote:
>
> (Removed Linus and Andrew from the To, added Corinna ..)
and resending again without HTML (sorry, thought I had HTML-emails
disabled by default)
>
> On Thu, Sep 3, 2015 at 1:35 AM, David Miller
> On Sep 7, 2015, at 4:02 AM, David Laight wrote:
>
> Feed:
> int bar(int (*f)[10]) { return sizeof *f; }
> into cc -O2 -S and look at the generated code - returns 40 not 4.
Yes, indeed it does. And with clang too. I guess I was too easily discouraged
when looking for
From: Rustad, Mark D
...
> >> static int smp_ah(struct crypto_blkcipher *tfm, const u8 irk[16],
> >> const u8 r[3], u8 res[3])
> >
> > Expect that it looks like you are passing arrays by value,
> > but instead you are passing by reference.
> >
> > Explicitly pass by reference and
1 - 100 of 125 matches
Mail list logo