From: ebiederm@xmission.com.z (Eric W. Biederman)
To: Greg KH <greg@kroah.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Benjamin Thery <benjamin.thery@bull.net>,
NeilBrown <neilb@suse.de>
Subject: Re: linux-next: build failure after merge of the staging-next tree
Date: Sat, 01 May 2010 21:55:29 -0700 [thread overview]
Message-ID: <m1sk6a9a2m.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20100501174853.GA22217@kroah.com> (Greg KH's message of "Sat\, 1 May 2010 10\:48\:53 -0700")
Greg KH <greg@kroah.com> writes:
> On Fri, Apr 30, 2010 at 03:52:05PM +1000, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> After merging the staging-next tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/md/md.c: In function 'level_store':
>> drivers/md/md.c:3029: error: too few arguments to function 'sysfs_get_dirent'
>>
>> Caused by commit 262f8e4937e7b4a587923ca3c039a184668f49ec ("sysfs:
>> Implement sysfs tagged directory support") from the driver-core tree
>> interacting with commit fecc531e3cc0de60514d326c7d82f1075ed55888 ("md:
>> manage redundancy group in sysfs when changing level") from the md.
>>
>> I have applied this fixup patch for today and can carry it as necessary.
>
> Thanks, that would be great.
>
>> [This could have been avoided, of course, by creating a new API (maybe
>> sysfs_get_dirent_tagged) and implementing the old API in terms of that].
>
> Hm Eric, any thoughts?
I believe I touched all of the users of sysfs_get_dirent outside of sysfs
that existed when I sent you the patch.
Right now using sysfs_get_dirent is a hack to support notifications of
changes to sysfs files from atomic contexts, where sysfs_notify is
unsafe because it sleeps on sysfs_mutex. There are maybe 5 callers of
sysfs_get_dirent outside of sysfs. Given that we have a nice compile
time error I don't think it makes sense to have multiple versions of the
function.
It will probably makes sense at some point to go through and push
everything to using a less hacky solution, but for the moment the
solution is correct and doesn't cause too much pain so I'm not too
worried about it.
As for the fixup patch itself it looked correct.
Eric
next prev parent reply other threads:[~2010-05-02 4:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 5:52 linux-next: build failure after merge of the staging-next tree Stephen Rothwell
2010-04-30 14:43 ` Greg KH
2010-05-18 5:30 ` Neil Brown
2010-05-21 23:36 ` Greg KH
2010-05-22 0:20 ` Neil Brown
2010-05-22 14:49 ` Greg KH
2010-05-22 15:54 ` Sage Weil
2010-05-01 17:48 ` Greg KH
2010-05-02 4:55 ` Eric W. Biederman [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-04-30 5:52 Stephen Rothwell
2010-04-30 14:41 ` Greg KH
2010-04-30 5:50 Stephen Rothwell
2010-04-30 14:45 ` Greg KH
2010-04-30 15:08 ` Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1sk6a9a2m.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com.z \
--cc=benjamin.thery@bull.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=neilb@suse.de \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox