Re: [PATCH 02/10] nf_conntrack: Introduces a extension infrastructure

[Patrick McHardy <kaber@trash.net>]

Yasuyuki KOZAKAI wrote:
> Hi, Patrick,
> 
> Thanks for your review. I'm impressed with your huge works in many areas.
> I've applied your suggestions, except following.
> 
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 25 Jun 2007 12:01:02 +0200
> 
> 
>>>+void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, int gfp)
>>
>>
>>Does any caller actually use something besides GFP_ATOMIC for gfp?
> 
> 
> nf_conntrack_netlink does that.


I missed that, thanks.

>>>+{
>>>+	struct nf_ct_ext *new;
>>>+	int i, newlen, newoff;
>>>+	struct nf_ct_ext_type *t;
>>>+
>>>+	if (!ct->ext)
>>>+		return nf_ct_ext_create(&ct->ext, id, gfp);
>>>+
>>>+	if (nf_ct_ext_exist(ct, id))
>>>+		return NULL;
>>>+
>>>+	rcu_read_lock();
>>>+	t = rcu_dereference(nf_ct_ext_types[id]);
>>>+	BUG_ON(t == NULL);
>>>+
>>>+	newoff = ALIGN(ct->ext->len, t->align);
>>>+	newlen = newoff + t->len;
>>>+	rcu_read_unlock();
>>>+
>>>+	if (newlen >= ct->ext->real_len) {
>>>+		new = kmalloc(newlen, gfp);
>>>+		if (!new)
>>>+			return NULL;
>>>+
>>>+		memcpy(new, ct->ext, ct->ext->len);
>>
>>And maybe krealloc here?
> 
> 
> krealloc() is possible to free old area before t->move().
> That breaks list used by NAT.


You're right, thanks.