From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757212AbcJYPqw (ORCPT ); Tue, 25 Oct 2016 11:46:52 -0400 Received: from mail-oi0-f52.google.com ([209.85.218.52]:35652 "EHLO mail-oi0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755929AbcJYPqu (ORCPT ); Tue, 25 Oct 2016 11:46:50 -0400 MIME-Version: 1.0 In-Reply-To: <20161025140333.GB4326@redhat.com> References: <20161025110508.9052-1-roman.penyaev@profitbricks.com> <20161025140333.GB4326@redhat.com> From: Roman Penyaev Date: Tue, 25 Oct 2016 17:46:02 +0200 Message-ID: Subject: Re: [PATCH v3 1/1] kthread: allocate kthread structure using kmalloc To: Oleg Nesterov Cc: Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Tejun Heo , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 25, 2016 at 4:03 PM, Oleg Nesterov wrote: > On 10/25, Roman Pen wrote: >> >> This patch avoids allocation of kthread structure on a stack, and simply >> uses kmalloc. > > Oh. I didn't even read this patch, but I have to admit I personally do not > like it. I can be wrong, but imo this is the step to the wrong direction. it targets only one thing - we can't use stack anymore for keeping kthread structure on it. so basically it is not even a step, just an attempt to fix memory corruption after oops. > struct kthread is already bloated, we should not bloat it more. that is clear, but I wanted to keep code simpler with one allocation and one structure for all the needs. > Instead we should kill it. And to_kthread() too, at least in its current > form. that is nice and this is a step forward, but not with this patch. > > For example. parked/exited/cpu should go into smp_hotplug_thread. Yes, > this needs cleanups. > > All we need is kthread_data() which returns the pointer to the private > data used by kthread. that means that we still need to store the private data inside task_struct and probably again abuse some member. > > As for kthread_stop(), we no longer need to abuse ->vfork_done, we can > use task_works: yes, that can be done easily. in the current patch I already use the task_work to free the kthread structure. but still for me is not clear where to keep the private data if you have only task_struct in your hands. -- Roman