Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, 24 Jan 2018, Conrad Meyer wrote: On Wed, Jan 24, 2018 at 10:05 AM, Warner Losh wrote: ... Let's start with his point about u_long vs size_t causing problems: void*malloc(unsigned long size, struct malloc_type *type, int flags) vs void*mallocarray(size_t

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 2:40 PM, Conrad Meyer wrote: > On Wed, Jan 24, 2018 at 1:13 PM, Warner Losh wrote: > > mallocarray should be the last line of defense, not the only line of > > defense. > > Agreed. > > > most of the time, it's more correct to say > > >

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 1:13 PM, Warner Losh wrote: > mallocarray should be the last line of defense, not the only line of > defense. Agreed. > most of the time, it's more correct to say > > if (WOULD_OVERFLOW(a,b)) > return EINVAL; > ptr = mallocarray(a,b...); Disagree --

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 12:40 PM, Conrad Meyer wrote: > On Wed, Jan 24, 2018 at 11:27 AM, Warner Losh wrote: > > > > Which is why we should add check overflows for most of the no wait cases. > > They should be checked, but not primarily with mallocarray... > >

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 11:27 AM, Warner Losh wrote: > > Which is why we should add check overflows for most of the no wait cases. > They should be checked, but not primarily with mallocarray... I don't understand what the distinction is here. Can you help me understand why the

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Jan 24, 2018 12:24 PM, "Conrad Meyer" wrote: On Wed, Jan 24, 2018 at 10:51 AM, Pedro Giffuni wrote: > FWIW, I suggested a panic for M_WAITOK and returning NULL for M_NOWAIT, but > cem didn't like it because it was inconsistent. > > I think the current

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 10:44 AM, Pedro Giffuni wrote: > ... > On 24/01/2018 13:30, Conrad Meyer wrote: >> >> ... >> size_t can handle 10GB, but u_long can't. >> This whole argument hinges upon incorrect assumption that size_t is >> larger than u_long. > > > Hmm... > > Lets just

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 10:51 AM, Pedro Giffuni wrote: > FWIW, I suggested a panic for M_WAITOK and returning NULL for M_NOWAIT, but > cem didn't like it because it was inconsistent. > > I think the current argument is more about the size/trigger than the > behavior though.

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On 24/01/2018 13:40, Hans Petter Selasky wrote: On 01/24/18 19:28, Warner Losh wrote: Does mallocarray(10 ,1Gb) panic on i386? It does not. It should. Hi, If M_WAITOK is specified, then sleep forever and print a message. Else return NULL ? FWIW, I suggested a panic for M_WAITOK and

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

... On 24/01/2018 13:30, Conrad Meyer wrote: ... size_t can handle 10GB, but u_long can't. This whole argument hinges upon incorrect assumption that size_t is larger than u_long. Hmm... Lets just make it "unsigned long" to be consistent with malloc(9) and avoid confusion? Pedro.

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 10:40 AM, Hans Petter Selasky wrote: > On 01/24/18 19:28, Warner Losh wrote: >> >> Does mallocarray(10 ,1Gb) panic on i386? It does not. It should. > > > Hi, > > If M_WAITOK is specified, then sleep forever and print a message. > Else return NULL ?

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Jan 24, 2018 11:33 AM, "Conrad Meyer" wrote: Bruce didn't get this wrong, you've just misread his (style / opinion) complaint as an actual bug (which is kind of the whole reason why it's hard to treat his complaints seriously): > size_t happens to have the same

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On 01/24/18 19:28, Warner Losh wrote: Does mallocarray(10 ,1Gb) panic on i386? It does not. It should. Hi, If M_WAITOK is specified, then sleep forever and print a message. Else return NULL ? --HPS ___ svn-src-head@freebsd.org mailing list

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

Bruce didn't get this wrong, you've just misread his (style / opinion) complaint as an actual bug (which is kind of the whole reason why it's hard to treat his complaints seriously): > size_t happens to have the same representation as u_long on all supported > arches So yes, the check works on

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 10:05 AM, Warner Losh wrote: > It changes the fundamental 'can't fail' allocations into 'maybe panic' > allocations, which was my big objection. No, it doesn't make any such change. The only calls that will panic now would have "succeeded" before but

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

Does mallocarray(10 ,1Gb) panic on i386? It does not. It should. Warner On Jan 24, 2018 11:20 AM, "Conrad Meyer" wrote: > Please point out what in Bruce's rant is actually relevant. Again, I > usually start reading them and get sidetracked in things that are > opinions

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 11:05:24AM -0700, Warner Losh wrote: > Let's start with his point about u_long vs size_t causing problems: > > void*malloc(unsigned long size, struct malloc_type *type, int flags) > vs > void*mallocarray(size_t nmemb, size_t size, struct malloc_type *type, > >

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

Please point out what in Bruce's rant is actually relevant. Again, I usually start reading them and get sidetracked in things that are opinions stated as fact, or outright incorrect. At which point, I give up on them. ___ svn-src-head@freebsd.org

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On 01/24/18 12:37, Conrad Meyer wrote: On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni wrote: On 23/01/2018 14:08, Conrad Meyer wrote: On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: Author: pfg Date: Sun Jan 21 15:42:36 2018 New Revision:

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 10:34 AM, Conrad Meyer wrote: > On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote: > > I agree completely. It doesn't do what you think it is doing, for all the > > reasons that Bruce outlines. We thought it was a bad idea when it came

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, 2018-01-24 at 09:34 -0800, Conrad Meyer wrote: > On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote: > > > > I agree completely. It doesn't do what you think it is doing, for all the > > reasons that Bruce outlines. We thought it was a bad idea when it came up 2 > >

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni wrote: > On 23/01/2018 14:08, Conrad Meyer wrote: >> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: >>> >>> Author: pfg >>> Date: Sun Jan 21 15:42:36 2018 >>> New Revision: 328218 >> >> I'm confused

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote: > I agree completely. It doesn't do what you think it is doing, for all the > reasons that Bruce outlines. We thought it was a bad idea when it came up 2 > years ago and nothing has really changed. I disagree. I'm not sure

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On 01/24/18 03:50, Bruce Evans wrote: On Tue, 23 Jan 2018, Pedro Giffuni wrote: On 23/01/2018 14:08, Conrad Meyer wrote: Hi Pedro, On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: Author: pfg Date: Sun Jan 21 15:42:36 2018 New Revision: 328218 URL:

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Wed, Jan 24, 2018 at 1:50 AM, Bruce Evans wrote: > On Tue, 23 Jan 2018, Pedro Giffuni wrote: > > On 23/01/2018 14:08, Conrad Meyer wrote: >> >>> Hi Pedro, >>> >>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni >>> wrote: >>> Author: pfg

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On Tue, 23 Jan 2018, Pedro Giffuni wrote: On 23/01/2018 14:08, Conrad Meyer wrote: Hi Pedro, On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: Author: pfg Date: Sun Jan 21 15:42:36 2018 New Revision: 328218 URL: https://svnweb.freebsd.org/changeset/base/328218 Log:

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

Hi; On 23/01/2018 17:13, Bryan Drewery wrote: On 1/23/2018 11:40 AM, Pedro Giffuni wrote: Hi; On 23/01/2018 14:08, Conrad Meyer wrote: Hi Pedro, On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: Author: pfg Date: Sun Jan 21 15:42:36 2018 New Revision: 328218 URL:

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

On 1/23/2018 11:40 AM, Pedro Giffuni wrote: > Hi; > > > On 23/01/2018 14:08, Conrad Meyer wrote: >> Hi Pedro, >> >> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni >> wrote: >>> Author: pfg >>> Date: Sun Jan 21 15:42:36 2018 >>> New Revision: 328218 >>> URL:

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

Hi; On 23/01/2018 14:08, Conrad Meyer wrote: Hi Pedro, On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: Author: pfg Date: Sun Jan 21 15:42:36 2018 New Revision: 328218 URL: https://svnweb.freebsd.org/changeset/base/328218 Log: Revert r327828, r327949, r327953,

Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev

Hi Pedro, On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: > Author: pfg > Date: Sun Jan 21 15:42:36 2018 > New Revision: 328218 > URL: https://svnweb.freebsd.org/changeset/base/328218 > > Log: > Revert r327828, r327949, r327953, r328016-r328026, r328041: > Uses of