What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?

What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?

[Kevin Wilson]

In SMP kernels 2.6.21 and prior you could use a SOCK's sendmsg() call via the PROTO structure directly. e.g., sock->sk_prot->sendmsg().

Now in 2.6.22 and later kernels you must use the higher level SOCKET to make a call to PROTO_OPS then to sendmsg(). e.g., socket->ops->sendmsg().

Would someone please clue me in as to what source changes caused previously working driver code to go belly up? (ref original post below) I tried finding it in git but I don't think this was intentional but rather a side effect of some other change made between .21 & .22.

The 2nd method fixes the kernel oops I reported. Thanks to all those that assisted me (0) with my first post to this list (see below) ... uh, oh yeah, did I mention that number would tally up to ZERO people. ;-}

Thanks,

Kevin

***********************************************************************
-----Original Message-----
From: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org]On Behalf Of Kevin Wilson
Sent: Tuesday, December 11, 2007 16:51
To: netdev@vger.kernel.org
Subject: sk_prot->sendmsg(...) giving me a kernel oops on kernels past
2.6.20


I've searched everywhere (including this list) for a report but couldn't
find anything that can tell me what implementation step(s) I am missing.
Essentially all the kernels past 2.6.20 gives me a kernel oops on the
sendmsg code.

I know the sk_buff changes worked things over quite a bit but I have (or
thought I did) those changes accounted for in our driver. Are there any
specific implementation changes we need to add that we didn't need prior
before we now use sendmsg()? Below is the general gist of the code I am
executing, any pointers to what I am missing would be very welcome.

Thanks a bunch.

Kevin

***************************************
done in userland and passed via ioctl:
***************************************

sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

tcp_params.boxid = boxIndex;
tcp_params.sk = sk;
tcp_params.rbuf = malloc(4096);
tcp_params.rbuf_size = 4096;
tcp_params.wbuf = malloc(1460);
tcp_params.wbuf_size = 1460;

rc = ioctl(fd, SI_SET_TCP, &tcp_params);

***************************************
done in kernel space:
***************************************

struct tcp_sock *tp;
struct sock *mysock;

tp = sockfd_lookup(tcp_params.sk, &i);

mysock = tp->sk;

mysock->sk_prot->sendmsg(...);	<-- OOPS HERE

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?

[David Miller]

From: "Kevin Wilson" <Kevin.Wilson@comtrol.com>
Date: Thu, 13 Dec 2007 14:54:31 -0600

> The 2nd method fixes the kernel oops I reported. Thanks to all those
> that assisted me (0) with my first post to this list (see below)
> ... uh, oh yeah, did I mention that number would tally up to ZERO
> people. ;-}

Because the knowledgable folks here have zero interest in helping
people with out-of-tree-likely-binary-only modules, because in such
cases you have our code but we don't have your's.

Have a nice day.

RE: What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?

[Kevin Wilson]

I see your point but it just so happens it is a GPL'd driver, as is all of our Linux code we produce for our hardware. Granted it is out of tree, and after you saw it you would want it to stay that way. However, I would have sent you the whole thing if that is a pre-req to cordial exchanges on this list.

Nonetheless, a somewhat recent change in your tree, that I could not pinpoint on my own, caused the driver to stop functioning properly. So after much searching in git/google/sources with no luck, I decided to ask for a little assistance, maybe just a hint as to where the culprit may be in the tree so I could investigate for myself. For SNGs I tried the method that now works but I am still at a loss as to (can't find) what changes in the tree caused it to fail.

Does that now clarify/help matters any?

Regards,

Kevin

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Thursday, December 13, 2007 15:18
To: Kevin Wilson
Cc: netdev@vger.kernel.org
Subject: Re: What was the reason for 2.6.22 SMP kernels to change how
sendmsg is called?


From: "Kevin Wilson" <Kevin.Wilson@comtrol.com>
Date: Thu, 13 Dec 2007 14:54:31 -0600

> The 2nd method fixes the kernel oops I reported. Thanks to all those
> that assisted me (0) with my first post to this list (see below)
> ... uh, oh yeah, did I mention that number would tally up to ZERO
> people. ;-}

Because the knowledgable folks here have zero interest in helping
people with out-of-tree-likely-binary-only modules, because in such
cases you have our code but we don't have your's.

Have a nice day.

RE: What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?

[Brandeburg, Jesse]

Kevin Wilson wrote:
> Nonetheless, a somewhat recent change in your tree, that I could not
> pinpoint on my own, caused the driver to stop functioning properly.
> So after much searching in git/google/sources with no luck, I decided
> to ask for a little assistance, maybe just a hint as to where the
> culprit may be in the tree so I could investigate for myself. For
> SNGs I tried the method that now works but I am still at a loss as to
> (can't find) what changes in the tree caused it to fail.      

Kevin, could you give git-bisect a shot?  if you have two kernel
versions or -rcX tags that work and don't work, then you can use bisect
to help find the patch that causes it.

you can search for from:torvalds and git-bisect to see lots of
instructions from Linus on how to do it.  If you have a fast machine and
a few hours and an automatable test it can go really fast, probably less
than 12 rebuilds.

Good Luck,
  Jesse

Re: What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?

[Evgeniy Polyakov]

Hi Kevin.

On Thu, Dec 13, 2007 at 04:00:02PM -0600, Kevin Wilson (Kevin.Wilson@comtrol.com) wrote:
> I see your point but it just so happens it is a GPL'd driver, as is all of our Linux code we produce for our hardware. Granted it is out of tree, and after you saw it you would want it to stay that way. However, I would have sent you the whole thing if that is a pre-req to cordial exchanges on this list.
> 
> Nonetheless, a somewhat recent change in your tree, that I could not pinpoint on my own, caused the driver to stop functioning properly. So after much searching in git/google/sources with no luck, I decided to ask for a little assistance, maybe just a hint as to where the culprit may be in the tree so I could investigate for myself. For SNGs I tried the method that now works but I am still at a loss as to (can't find) what changes in the tree caused it to fail.

Without having your code it is virtually impossible to say, why you have
a bug. And do not express your frustration telling 'zero people
responded to my bug report'. This was not a bug report at all, but empty
message about 'my code stopped working after some network changes, which
broke the stuff.

>Now in 2.6.22 and later kernels you must use the higher level SOCKET to
>make a call to PROTO_OPS then to sendmsg(). e.g., socket->ops->sendmsg().

It was done because of bug found in inet_sendmsg(), which tried to
autobind socket it should not try.

-- 
	Evgeniy Polyakov

RE: What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?

[Kevin Wilson]

>>do not express your frustration ...

wasn't frustration but rather playful sarcasm.

>>This was not a bug report at all...

Wasn't really meant to be a true blue bug report (my bad I guess). Anywho, I know you guys have big fish to fry so I tried to keep it short and to the point. I knew something had changed and I was truly stumped in trying to figure out what it was so I decided to ask for some general guidance. 

>>Without having your code it is virtually impossible to say.

I know this is partly my own fault for not stating so explicitly in my first email. However, as I stated in my second email, I would have been happy to send it to anyone that expressed an interest (even though the issue wasn't interesting in itself) in my post. I just thought, being the experts you are, that having only the small subset of code that is actually involved in the offending call, you'd be able to say "go take a look at commit such-n-such" which you have now done. Thanks a million!

I'm not trying to start a nag war here, I know you guys are busy. Having both (mostly me) made pitiful assumptions I think we have reached an understanding on this (now dead) topic. I'm just starting out in the drivers arena with hopes of being a decent contributor to the kernel ecosystem some day so there will be some growing pains and this thread was one of them.

Thanks for the help and suggestions, I appreciate them immensely.

Kevin

 
-----Original Message-----
From: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org]On Behalf Of Evgeniy Polyakov
Sent: Friday, December 14, 2007 00:33
To: Kevin Wilson
Cc: David Miller; netdev@vger.kernel.org
Subject: Re: What was the reason for 2.6.22 SMP kernels to change how
sendmsg is called?


Hi Kevin.

On Thu, Dec 13, 2007 at 04:00:02PM -0600, Kevin Wilson (Kevin.Wilson@comtrol.com) wrote:
> I see your point but it just so happens it is a GPL'd driver, as is all of our Linux code we produce for our hardware. Granted it is out of tree, and after you saw it you would want it to stay that way. However, I would have sent you the whole thing if that is a pre-req to cordial exchanges on this list.
> 
> Nonetheless, a somewhat recent change in your tree, that I could not pinpoint on my own, caused the driver to stop functioning properly. So after much searching in git/google/sources with no luck, I decided to ask for a little assistance, maybe just a hint as to where the culprit may be in the tree so I could investigate for myself. For SNGs I tried the method that now works but I am still at a loss as to (can't find) what changes in the tree caused it to fail.

Without having your code it is virtually impossible to say, why you have
a bug. And do not express your frustration telling 'zero people
responded to my bug report'. This was not a bug report at all, but empty
message about 'my code stopped working after some network changes, which
broke the stuff.

>Now in 2.6.22 and later kernels you must use the higher level SOCKET to
>make a call to PROTO_OPS then to sendmsg(). e.g., socket->ops->sendmsg().

It was done because of bug found in inet_sendmsg(), which tried to
autobind socket it should not try.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html