All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH net-next 1/9] net: sctp: sctp_ssnmap: remove 'malloced' element from struct
Date: Wed, 17 Apr 2013 12:52:34 +0000	[thread overview]
Message-ID: <516E9B12.3040300@redhat.com> (raw)
In-Reply-To: <20130417124539.GA5149@hmsreliant.think-freely.org>

On 04/17/2013 02:45 PM, Neil Horman wrote:
> On Tue, Apr 16, 2013 at 11:07:10PM +0200, Daniel Borkmann wrote:
>> sctp_ssnmap_init() can only be called from sctp_ssnmap_new()
>> where malloced is always set to 1. Thus, when we call
>> sctp_ssnmap_free() the test for map->malloced evaluates always
>> to true.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> ---
>>   include/net/sctp/structs.h |  1 -
>>   net/sctp/ssnmap.c          | 23 ++++++++++++-----------
>>   2 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
>> index e12aa77..3c1bb8d 100644
>> --- a/include/net/sctp/structs.h
>> +++ b/include/net/sctp/structs.h
>> @@ -399,7 +399,6 @@ struct sctp_stream {
>>   struct sctp_ssnmap {
>>   	struct sctp_stream in;
>>   	struct sctp_stream out;
>> -	int malloced;
>>   };
>>
>>   struct sctp_ssnmap *sctp_ssnmap_new(__u16 in, __u16 out,
>> diff --git a/net/sctp/ssnmap.c b/net/sctp/ssnmap.c
>> index 825ea94..da86035 100644
>> --- a/net/sctp/ssnmap.c
>> +++ b/net/sctp/ssnmap.c
>> @@ -74,7 +74,6 @@ struct sctp_ssnmap *sctp_ssnmap_new(__u16 in, __u16 out,
>>   	if (!sctp_ssnmap_init(retval, in, out))
>>   		goto fail_map;
>>
>> -	retval->malloced = 1;
>>   	SCTP_DBG_OBJCNT_INC(ssnmap);
>>
>>   	return retval;
>> @@ -118,14 +117,16 @@ void sctp_ssnmap_clear(struct sctp_ssnmap *map)
>>   /* Dispose of a ssnmap.  */
>>   void sctp_ssnmap_free(struct sctp_ssnmap *map)
>>   {
>> -	if (map && map->malloced) {
>> -		int size;
>> -
>> -		size = sctp_ssnmap_size(map->in.len, map->out.len);
>> -		if (size <= KMALLOC_MAX_SIZE)
>> -			kfree(map);
>> -		else
>> -			free_pages((unsigned long)map, get_order(size));
>> -		SCTP_DBG_OBJCNT_DEC(ssnmap);
>> -	}
>> +	int size;
>> +
>> +	if (unlikely(!map))
>> +		return;
>> +
>> +	size = sctp_ssnmap_size(map->in.len, map->out.len);
>> +	if (size <= KMALLOC_MAX_SIZE)
>> +		kfree(map);
>> +	else
>> +		free_pages((unsigned long)map, get_order(size));
>> +
>> +	SCTP_DBG_OBJCNT_DEC(ssnmap);
>>   }
>> --
>> 1.7.11.7
>>
> I definately like what you're doing here, as the use of the ->malloced member
> always struck me as a half-assed way to try and avoid a double free that someone
> couldn't track down during this code's initial development.  That said, I'm
> wondering if the !map check is going to fail at some point, given that the call
> site for sctp_ssnmap_free never sets asoc->ssnmap to NULL after its call.  Maybe
> worthwhile adding such a NULL assoginment to the call site to ensure that we
> don't accidentally trigger a double free?

I'll test that with lksctp-tools suite and come back to you today.

Thanks,
Daniel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Borkmann <dborkman@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH net-next 1/9] net: sctp: sctp_ssnmap: remove 'malloced' element from struct
Date: Wed, 17 Apr 2013 14:52:34 +0200	[thread overview]
Message-ID: <516E9B12.3040300@redhat.com> (raw)
In-Reply-To: <20130417124539.GA5149@hmsreliant.think-freely.org>

On 04/17/2013 02:45 PM, Neil Horman wrote:
> On Tue, Apr 16, 2013 at 11:07:10PM +0200, Daniel Borkmann wrote:
>> sctp_ssnmap_init() can only be called from sctp_ssnmap_new()
>> where malloced is always set to 1. Thus, when we call
>> sctp_ssnmap_free() the test for map->malloced evaluates always
>> to true.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> ---
>>   include/net/sctp/structs.h |  1 -
>>   net/sctp/ssnmap.c          | 23 ++++++++++++-----------
>>   2 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
>> index e12aa77..3c1bb8d 100644
>> --- a/include/net/sctp/structs.h
>> +++ b/include/net/sctp/structs.h
>> @@ -399,7 +399,6 @@ struct sctp_stream {
>>   struct sctp_ssnmap {
>>   	struct sctp_stream in;
>>   	struct sctp_stream out;
>> -	int malloced;
>>   };
>>
>>   struct sctp_ssnmap *sctp_ssnmap_new(__u16 in, __u16 out,
>> diff --git a/net/sctp/ssnmap.c b/net/sctp/ssnmap.c
>> index 825ea94..da86035 100644
>> --- a/net/sctp/ssnmap.c
>> +++ b/net/sctp/ssnmap.c
>> @@ -74,7 +74,6 @@ struct sctp_ssnmap *sctp_ssnmap_new(__u16 in, __u16 out,
>>   	if (!sctp_ssnmap_init(retval, in, out))
>>   		goto fail_map;
>>
>> -	retval->malloced = 1;
>>   	SCTP_DBG_OBJCNT_INC(ssnmap);
>>
>>   	return retval;
>> @@ -118,14 +117,16 @@ void sctp_ssnmap_clear(struct sctp_ssnmap *map)
>>   /* Dispose of a ssnmap.  */
>>   void sctp_ssnmap_free(struct sctp_ssnmap *map)
>>   {
>> -	if (map && map->malloced) {
>> -		int size;
>> -
>> -		size = sctp_ssnmap_size(map->in.len, map->out.len);
>> -		if (size <= KMALLOC_MAX_SIZE)
>> -			kfree(map);
>> -		else
>> -			free_pages((unsigned long)map, get_order(size));
>> -		SCTP_DBG_OBJCNT_DEC(ssnmap);
>> -	}
>> +	int size;
>> +
>> +	if (unlikely(!map))
>> +		return;
>> +
>> +	size = sctp_ssnmap_size(map->in.len, map->out.len);
>> +	if (size <= KMALLOC_MAX_SIZE)
>> +		kfree(map);
>> +	else
>> +		free_pages((unsigned long)map, get_order(size));
>> +
>> +	SCTP_DBG_OBJCNT_DEC(ssnmap);
>>   }
>> --
>> 1.7.11.7
>>
> I definately like what you're doing here, as the use of the ->malloced member
> always struck me as a half-assed way to try and avoid a double free that someone
> couldn't track down during this code's initial development.  That said, I'm
> wondering if the !map check is going to fail at some point, given that the call
> site for sctp_ssnmap_free never sets asoc->ssnmap to NULL after its call.  Maybe
> worthwhile adding such a NULL assoginment to the call site to ensure that we
> don't accidentally trigger a double free?

I'll test that with lksctp-tools suite and come back to you today.

Thanks,
Daniel

  reply	other threads:[~2013-04-17 12:52 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16 21:07 [PATCH net-next 0/9] Minor SCTP cleanups all over the place Daniel Borkmann
2013-04-16 21:07 ` Daniel Borkmann
2013-04-16 21:07 ` [PATCH net-next 1/9] net: sctp: sctp_ssnmap: remove 'malloced' element from struct Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 12:45   ` Neil Horman
2013-04-17 12:45     ` Neil Horman
2013-04-17 12:52     ` Daniel Borkmann [this message]
2013-04-17 12:52       ` Daniel Borkmann
2013-04-17 17:17       ` Daniel Borkmann
2013-04-17 17:17         ` Daniel Borkmann
2013-04-17 19:18         ` Neil Horman
2013-04-17 19:18           ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 2/9] net: sctp: sctp_inq: remove dead code Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 12:47   ` Neil Horman
2013-04-17 12:47     ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 3/9] net: sctp: sctp_outq: remove 'malloced' from its struct Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 12:57   ` Neil Horman
2013-04-17 12:57     ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 4/9] net: sctp: sctp_outq: consolidate chars into bitfield Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17  8:43   ` David Laight
2013-04-17  8:43     ` David Laight
2013-04-17  9:26     ` Daniel Borkmann
2013-04-17  9:26       ` Daniel Borkmann
2013-04-17 15:27       ` Neil Horman
2013-04-17 15:27         ` Neil Horman
2013-04-17 15:35         ` Vlad Yasevich
2013-04-17 15:35           ` Vlad Yasevich
2013-04-17 15:40           ` Neil Horman
2013-04-17 15:40             ` Neil Horman
2013-04-17 15:38         ` Daniel Borkmann
2013-04-17 15:38           ` Daniel Borkmann
2013-04-17 15:44       ` Vlad Yasevich
2013-04-17 15:44         ` Vlad Yasevich
2013-04-17 15:31   ` Neil Horman
2013-04-17 15:31     ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 5/9] net: sctp: outqueue: simplify sctp_outq_uncork function Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 15:32   ` Neil Horman
2013-04-17 15:32     ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 6/9] net: sctp: sctp_transport: remove unused variable Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 15:34   ` Neil Horman
2013-04-17 15:34     ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 7/9] net: sctp: sctp_bind_addr: remove dead code Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 15:35   ` Neil Horman
2013-04-17 15:35     ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 8/9] net: sctp: sctp_ulpq: remove 'malloced' struct member Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 15:46   ` Neil Horman
2013-04-17 15:46     ` Neil Horman
2013-04-16 21:07 ` [PATCH net-next 9/9] net: sctp: sctp_ulpq: do not use char as a " Daniel Borkmann
2013-04-16 21:07   ` Daniel Borkmann
2013-04-17 15:36   ` Vlad Yasevich
2013-04-17 15:36     ` Vlad Yasevich
2013-04-17 15:41     ` Daniel Borkmann
2013-04-17 15:41       ` Daniel Borkmann
2013-04-17 15:45   ` Neil Horman
2013-04-17 15:45     ` Neil Horman
2013-04-17 16:28     ` David Laight
2013-04-17 16:28       ` David Laight
2013-04-17 18:13 ` [PATCH net-next 0/9] Minor SCTP cleanups all over the place David Miller
2013-04-17 18:13   ` David Miller
2013-04-17 18:55   ` Daniel Borkmann
2013-04-17 18:55     ` Daniel Borkmann

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=516E9B12.3040300@redhat.com \
    --to=dborkman@redhat.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.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.