From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 12 Apr 2005 13:23:54 -0500 From: Sam To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] page fault with lock held In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Topicbox-Message-UUID: 36a3ee4a-ead0-11e9-9d60-3106f5b1d025 I didn't fit into devsd because the device names (sdXn) weren't helpful and I need the ability to do extra control processing I couldn't see how to get from devsd. e.g., I currently have devices named aoe{major}.{minor}; the blade in shelf 10, slot 9 is aoe10.9/. This addressing mechanism is much easier to understand than any sd controller to ethernet controller mapping I could think up. Telling devaoe to start using interface ether0 is done with: echo bind /net/ether0 >aoectl There's also an aoeevents file our raid/lvm software can monitor (for device retransmits, eg). The interface is still rather pliable as I'm trying to figure out what will work best. For each system I've written an aoe driver someone has asked why I didn't fit into the current code. It always turns out that it's easier to cut a new one than bend the existing code to make it work. Disk drivers don't typically have to worry about multiple outstanding requests, retransmission timeouts, or anytime device discovery. This isn't to say they don't do command queueing or support hot plugging, it's just not usually something I can fit into. Thanks for the lock tip - Sam On Tue, 12 Apr 2005 jmk@plan9.bell-labs.com wrote: > no, you should not be holding a spinlock when trying that. > why is your driver trying to copy directly to user space, > isn't it a subdevice of devsd? (i'm not saying that's the way > to do it, just curious). > > On Tue Apr 12 13:20:53 EDT 2005, sah@softcardsystems.com wrote: >> Hello 9fans, >> >> I'm testing my AoE driver and have hit something curious. >> >> On devaoe.c read, after getting the sectors from the >> remote disk and when trying to copy the data to the >> user process using memmove, I get a write page fault. >> At the time, I happen to be holding a spinlock over >> the device structure, which causes both >> port/fault.c:/^fault/ and port/fault.c/^seg/ (via qlock) >> to squawk at me about up->nlocks.ref > 0. >> >> The user address in question is 7fffaedc. Firstly, does >> this address seem appropriate and secondly, is dropping >> the spinlock during the memmove appropriate? >> >> All signs point to yes, but I'd like some reassurance. >> >> Cheers, >> >> Sam >