From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754530AbcFQAMl (ORCPT ); Thu, 16 Jun 2016 20:12:41 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:36207 "EHLO mail-qk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753818AbcFQAMj (ORCPT ); Thu, 16 Jun 2016 20:12:39 -0400 From: Daniel Bristot de Oliveira X-Google-Original-From: Daniel Bristot de Oliveira Subject: Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock To: Tejun Heo , Daniel Bristot de Oliveira References: <1465325475-30593-1-git-send-email-bristot@redhat.com> <20160607193008.GA31708@htj.duckdns.org> <6f15f27f-3757-5413-4292-1386e95bc278@redhat.com> <38469b61-7cc5-5fec-4de3-0e9a616dfe95@redhat.com> <20160616220315.GH3262@mtj.duckdns.org> <20160616221434.GI3262@mtj.duckdns.org> Cc: linux-kernel@vger.kernel.org, Rik van Riel , "Luis Claudio R. Goncalves" , Li Zefan , Johannes Weiner , Juri Lelli , cgroups@vger.kernel.org, Steven Rostedt Message-ID: Date: Thu, 16 Jun 2016 21:12:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160616221434.GI3262@mtj.duckdns.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/16/2016 07:14 PM, Tejun Heo wrote: > Except that the patch seems to use irqsave/restore instead of plain > irq ones in places. Care to update those? Hi Tejun, The use of the irq spin_(un)lock_irq() assumes that the code is always called with IRQs enabled. But that is not always true in this case, as we call cgroup_free() in the hard IRQ context, and unconditionally enable IRQ in this context is a problem. So we need to use irqsave/restore. Discussing with rostedt, we figured that this needs to be IRQ safe (using irqsave/restore) in the PREEMPT RT too, so I need to code a v3 of this patch using raw_spin_*() functions to avoid this problem in the -rt kernel as well. Do you see any problems on this? Thanks! -- Daniel