Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934020Ab0HLVvQ (ORCPT ); Thu, 12 Aug 2010 17:51:16 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:43185 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760889Ab0HLVvP (ORCPT ); Thu, 12 Aug 2010 17:51:15 -0400 MIME-Version: 1.0 In-Reply-To: References: <201008122200.05598.thomas@m3y3r.de> <4C646110.1040104@gmail.com> From: Linus Torvalds Date: Thu, 12 Aug 2010 14:50:16 -0700 Message-ID: Subject: Re: 2.6.36: Sound stop working To: Takashi Iwai , Eric Paris , Al Viro Cc: Jiri Slaby , Pekka Enberg , Thomas Meyer , Linux Kernel Mailing List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1267 Lines: 27 On Thu, Aug 12, 2010 at 2:41 PM, Linus Torvalds wrote: > > Al, what was the problem that caused you to think that we want to have > a 'struct file' here? Is it just the fact that some of those fsnotify > things use that 'path' structure that is embedded in the parent? But > isn't the simplest fix for that to just _copy_ the "struct path" > rather than pass the "struct file" around? Btw, that's exactly what the fsnotify code does seem to do, in fsnotify_create_event(). So as far as I can tell, it's all ok - we only use that file->f_path pointer while we hold the file open, and then we copy it to event->path and increment the counts properly. Of course, maybe I'm missing some other case where we _don't_ copy the data, and pass a pointer to a file->f_path around that could get stale. Or maybe I'm missing some other worry entirely. But those games with f_count are just disgusting. The path-based thing seems to be much more straightforward. Linus -- 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/