Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] sdp: replace mlock with get_user_pages
>
> On Thu, May 05, 2005 at 02:01:58PM +0300, Michael S. Tsirkin wrote:
> > Hello, Libor!
> > The following patch replaces the mlock hack with call
> > to get_user_pages. Since the applicat
sk_alloc() already takes care of setting sk_family to proto. No need to
do it a second time in sdp.
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.11-o
This is an updated patch to SDP allowing it to work on 2.6.12-rc4 with
the new sock slab allocator. This applies cleanly on SDP rev 2277. It
also fixes a bug I had in v5 that would cause slab corruption on conn
destroy.
Please apply once 2.6.12-final is out.
Signed-off-by: Tom Duffy <[EMAIL PRO
On Thu, May 05, 2005 at 05:21:22PM -0700, Libor Michalek wrote:
> No point other then the obvious, changing the sign of the variables
>value. It's just a style convention that I have no problem changing.
- remove '0 operator factor' statements.
- a bit of whitespace removal.
- remove return at e
On Fri, 2005-05-06 at 02:30 +0200, Bernhard Fischer wrote:
> in src/linux-kernel/infiniband/ulp/sdp/sdp_inet.c
> module_param seem to be missing MODULE_PARM_DESC
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: linux/drivers/infiniband/ulp/sdp/sdp_inet.c
===
On Sat, 7 May 2005, Timur Tabi wrote:
>
> > Oh, well, maybe, but what is the real problem?
> > Are you sure that copy-on-write doesn't come into it?
>
> No, but I do know that my test case doesn't call fork(), so it's reproducible
> without involving COW. Of course, I'm sure someone's going to t
On Sat, 2005-05-07 at 01:54 -0400, Hal Rosenstock wrote:
> Is the client connecting to a server which is present or not ?
Yes, the client *is* connecting to the server. Here is the full client
side transaction:
[EMAIL PROTECTED] ~]# ./kdapltest -T Q -s 192.168.0.26 -D mthca0a -d
Server Name: 192
Hugh Dickins wrote:
Oh, well, maybe, but what is the real problem?
Are you sure that copy-on-write doesn't come into it?
No, but I do know that my test case doesn't call fork(), so it's reproducible without
involving COW. Of course, I'm sure someone's going to tell me now that COW comes into
eff
Sorry for not replying earlier (indeed, sorry for not joining in the
wider RDMA pinning discussion), concentrating on other stuff at present.
On Fri, 6 May 2005, Timur Tabi wrote:
> Timur Tabi wrote:
>
> > I haven't gotten a reply to this question, but I've done my own research,
> > and I think I
