Re: [9fans] page fault with lock held

[Sam <sah@softcardsystems.com>]

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
>