Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752641Ab2ECFqP (ORCPT ); Thu, 3 May 2012 01:46:15 -0400 Received: from cobra.newdream.net ([66.33.216.30]:48219 "EHLO cobra.newdream.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752083Ab2ECFqO (ORCPT ); Thu, 3 May 2012 01:46:14 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=newdream.net; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=newdream.net; b=FUSM2UFk8RU+n19L3/w6WoUKd PzVs9VKYa/cal9DDWAb8z704I+SXQjNud0zBnT/lkYQU3rM0LjKbDICBR5Ye8QnQ 97eiK+SQrPr+XYMJox5WTgUIL9joFU5O6G0ZNIQBVZLKLfs8ZyOypFB3IAjuZgu0 q18MwwCgD/uE3tN5bE= Date: Wed, 2 May 2012 22:46:12 -0700 (PDT) From: Sage Weil To: Minchan Kim cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kosaki.motohiro@gmail.com, rientjes@google.com, Neil Brown , Artem Bityutskiy , David Woodhouse , "Theodore Ts'o" , Adrian Hunter , Steven Whitehouse , "David S. Miller" , James Morris , Alexander Viro Subject: Re: [PATCH] vmalloc: add warning in __vmalloc In-Reply-To: <4FA1D93C.9000306@kernel.org> Message-ID: References: <1335932890-25294-1-git-send-email-minchan@kernel.org> <20120502124610.175e099c.akpm@linux-foundation.org> <4FA1D93C.9000306@kernel.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2203 Lines: 88 On Thu, 3 May 2012, Minchan Kim wrote: > On 05/03/2012 04:46 AM, Andrew Morton wrote: > > Well. What are we actually doing here? Causing the kernel to spew a > > warning due to known-buggy callsites, so that users will report the > > warnings, eventually goading maintainers into fixing their stuff. > > > > This isn't very efficient :( > > > Yes. I hope maintainers fix it before merging this. > > > > > It would be better to fix that stuff first, then add the warning to > > prevent reoccurrences. Yes, maintainers are very naughty and probably > > do need cattle prods^W^W warnings to motivate them to fix stuff, but we > > should first make an effort to get these things fixed without > > irritating and alarming our users. > > > > Where are these offending callsites? Okay, maybe this is a stupid question, but: if an fs can't call vmalloc with GFP_NOFS without risking deadlock, calling with GFP_KERNEL instead doesn't fix anything (besides being more honest). This really means that vmalloc is effectively off-limits for file systems in any writeback-related path, right? sage > > > dm: > __alloc_buffer_wait_no_callback > > ubi: > ubi_dbg_check_write > ubi_dbg_check_all_ff > > ext4 : > ext4_kvmalloc > > gfs2 : > gfs2_alloc_sort_buffer > > ntfs : > __ntfs_malloc > > ubifs : > dbg_dump_leb > scan_check_cb > dump_lpt_leb > dbg_check_ltab_lnum > dbg_scan_orphans > > mm : > alloc_large_system_hash > > ceph : > fill_inode > ceph_setxattr > ceph_removexattr > ceph_x_build_authorizer > ceph_decode_buffer > ceph_alloc_middle > > > > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-mm' in > > the body to majordomo@kvack.org. For more info on Linux MM, > > see: http://www.linux-mm.org/ . > > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > > Don't email: email@kvack.org > > > > > > -- > Kind regards, > Minchan Kim > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/