pre8

pre8

[Alasdair G Kergon]

I appear to have almost succeeded in squeezing 0.4.4-pre8 into 
RHEL4 U1, but I doubt I'll be allowed any more updates now except 
for severe bugs.

Alasdair

Re: pre8

[Christophe Varoqui]

On Tue, Apr 05, 2005 at 10:32:23PM +0100, Alasdair G Kergon wrote:
> I appear to have almost succeeded in squeezing 0.4.4-pre8 into 
> RHEL4 U1, but I doubt I'll be allowed any more updates now except 
> for severe bugs.
> 
Just to let you you know what I think is still needed before 0.4.4 :

o memory allocation error paths audit (mostly done in pre9)
o don't loose events in multipathd
o /dev/shm/cache has the same security problems you spotted in /tmp

I guess this last item will help justify your upgrading to 0.4.4

Regards,
cvaroqui

Re: pre8

[Mike Christie]

Christophe Varoqui wrote:
> On Tue, Apr 05, 2005 at 10:32:23PM +0100, Alasdair G Kergon wrote:
> 
>>I appear to have almost succeeded in squeezing 0.4.4-pre8 into 
>>RHEL4 U1, but I doubt I'll be allowed any more updates now except 
>>for severe bugs.
>>
> 
> Just to let you you know what I think is still needed before 0.4.4 :
> 
> o memory allocation error paths audit (mostly done in pre9)

The pathcheckers use sgio, right? The block layer sg io code does some 
allocations with GFP_KERNEL (bio_copy_user and bio_map_user for 
example), so if you are relying on that path for failback I think you 
will be in trouble.

> o don't loose events in multipathd
> o /dev/shm/cache has the same security problems you spotted in /tmp
> 
> I guess this last item will help justify your upgrading to 0.4.4
> 
> Regards,
> cvaroqui
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> 

Re: pre8

[christophe varoqui]

On mer, 2005-04-06 at 09:02 -0700, Mike Christie wrote:
> Christophe Varoqui wrote:
> > On Tue, Apr 05, 2005 at 10:32:23PM +0100, Alasdair G Kergon wrote:
> > 
> >>I appear to have almost succeeded in squeezing 0.4.4-pre8 into 
> >>RHEL4 U1, but I doubt I'll be allowed any more updates now except 
> >>for severe bugs.
> >>
> > 
> > Just to let you you know what I think is still needed before 0.4.4 :
> > 
> > o memory allocation error paths audit (mostly done in pre9)
> 
> The pathcheckers use sgio, right? The block layer sg io code does some 
> allocations with GFP_KERNEL (bio_copy_user and bio_map_user for 
> example), so if you are relying on that path for failback I think you 
> will be in trouble.
> 
Indeed.
Do you have suggestions to work around this issue ?

Regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

Re: pre8

[Mike Christie]

christophe varoqui wrote:
> On mer, 2005-04-06 at 09:02 -0700, Mike Christie wrote:
> 
>>Christophe Varoqui wrote:
>>
>>>On Tue, Apr 05, 2005 at 10:32:23PM +0100, Alasdair G Kergon wrote:
>>>
>>>
>>>>I appear to have almost succeeded in squeezing 0.4.4-pre8 into 
>>>>RHEL4 U1, but I doubt I'll be allowed any more updates now except 
>>>>for severe bugs.
>>>>
>>>
>>>Just to let you you know what I think is still needed before 0.4.4 :
>>>
>>>o memory allocation error paths audit (mostly done in pre9)
>>
>>The pathcheckers use sgio, right? The block layer sg io code does some 
>>allocations with GFP_KERNEL (bio_copy_user and bio_map_user for 
>>example), so if you are relying on that path for failback I think you 
>>will be in trouble.
>>
> 
> Indeed.
> Do you have suggestions to work around this issue ?
> 

For the bio allocation couldn't they just be made to do atomic 
allocations or ones that wait but do not cause IO (__GFP_WAIT/GFP_NOIO?)?

The other allocations could be made to not use GFP_KERNEL too, but they 
of course do not have mempools like the bios so there would still be 
that problem. At least we are not going to block on a write to the same 
disk we are trying to failback though.

Instead, what if the daemon that drives the path testing stays in the 
kernel, but the component that sends the command was in a dm-multipath 
module? We would never need more than one command per queue for testing 
outstanding, so if there was a path testing handler in the kernel the 
daemon would instruct that handler to send off its command. The testing 
handler would just have a command and other resources preallocated or 
use the kernel's preallocated resources, like using blk_get_request 
which uses the queue's mempool, when it could. And then it would just 
insert the command like the hw_handlers do - the preallocation is like 
the hw_handlers too. Maybe at that point though people would just 
consider putting the whole thing in the kernel since my idea seems like 
a hack to bypass the sg io paths instead of fixing them (or maybe the sg 
io paths were not supposed to be used for failback and failover?).

For iscsi I had begun to make a tester that just writes to a transport 
class sysfs file (another allocation :) I know, but it does not have to 
be sysfs - it is just what everyone happened to be using at the time), 
which in turn instructs the driver to send a iscsi ping. This is similar 
to above.


> Regards,