From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: [OT Re: Question: Variable sized matchinfo Date: Tue, 21 Jan 2003 17:32:46 +0100 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <3E2D762E.1040001@trash.net> References: <20030120232634.24011.21218.Mailman@kashyyyk> <15916.60267.562015.732567@isis.cs3-inc.com> <3E2D3218.1040805@trash.net> <20030121170702.B24205@linux.karinthy.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Don Cohen , netfilter-devel@lists.netfilter.org Return-path: To: Laszlo Valko In-Reply-To: <20030121170702.B24205@linux.karinthy.hu> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org Laszlo Valko wrote: >On Tue, Jan 21, 2003 at 12:42:16PM +0100, Patrick McHardy wrote: > > >>Oops, i probably missed that. >>Anyway this doesn't seem to be real problem, you could just pass pointers >>and copy_from_user the data. The probleme there is the match is not informed >>if its not needed anymore, so no chance to free the memory. >> >> > >But consider that the pointer on the kernel-side might not look like >what it looks like on the user-side! > >See my patch earlier with a sparc64 compatibility fix. Basically, >you will have to implement a thunk which translates the 32-bit userspace >pointer sent from iptables to a 64-bit kernelspace pointer. The best >solution is to avoid pointers, as the pointer translation usually involves >translating the whole struct being passed because of the field >offset differences. > >Laszlo > > you're right of course .. one question: i see copy_from_user in many places in the kernel, often within with user supplied addresses. Do all of these don't work on sparc64 ? what a horrible architecture ;) regards, patrick