From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756817AbbAZTzT (ORCPT ); Mon, 26 Jan 2015 14:55:19 -0500 Received: from resqmta-po-11v.sys.comcast.net ([96.114.154.170]:44605 "EHLO resqmta-po-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753818AbbAZTzQ (ORCPT ); Mon, 26 Jan 2015 14:55:16 -0500 Date: Mon, 26 Jan 2015 13:55:14 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Vladimir Davydov cc: Andrew Morton , Pekka Enberg , David Rientjes , Joonsoo Kim , Johannes Weiner , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -mm 2/3] slab: zap kmem_cache_shrink return value In-Reply-To: <20150126194838.GB2660@esperanza> Message-ID: References: <20150126170418.GC28978@esperanza> <20150126194838.GB2660@esperanza> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 26 Jan 2015, Vladimir Davydov wrote: > Hmm, why? The return value has existed since this function was > introduced, but nobody seems to have ever used it outside the slab core. > Besides, this check is racy, so IMO we shouldn't encourage users of the > API to rely on it. That said, I believe we should drop the return value > for now. If anybody ever needs it, we can reintroduce it. The check is only racy if you have concurrent users. It is not racy if a subsystem shuts down access to the slabs and then checks if everything is clean before closing the cache. Slab creation and destruction are not serialized. It is the responsibility of the subsystem to make sure that there are no concurrent users and that there are no objects remaining before destroying a slab.