James Bottomley <[email protected]> writes: > On Mon, 2012-09-10 at 15:07 -0400, David Miller wrote: >> From: [email protected] (Eric W. Biederman) >> Date: Fri, 07 Sep 2012 15:39:21 -0700 >> >> > >> > The scsi netlink code confuses the netlink port id with a process id, >> > going so far as to read NETLINK_CREDS(skb)->pid instead of the correct >> > NETLINK_CB(skb).pid. Fortunately it does not matter because nothing >> > registers to respond to scsi netlink requests. >> > >> > The only interesting use of the scsi_netlink interface is >> > fc_host_post_vendor_event which sends a netlink multicast message. >> > >> > Since nothing registers to handle scsi netlink messages kill all of the >> > registration logic, while retaining the same error handling behavior >> > preserving the userspace visible behavior and removing all of the >> > confused code that thought a netlink port id was a process id. >> > >> > This was tested with a kernel allyesconfig build which had no problems. >> > >> > Cc: James Bottomley <[email protected]> >> > Cc: James Smart <[email protected]> >> > Signed-off-by: "Eric W. Biederman" <[email protected]> >> >> James et al., please review and ACK. > > I'll defer to the decision of James Smart and the other FC contributors, > since the FC transport class is really the only one using a netlink > interface.
So just for curiosity I searched the entire git history for scsi_nl_add_ and the only commit that I found was the addition of that code to the tree in August of 2008. Does anyone have any reason to keep scsi_nl_add_transport or scsi_nl_add_driver that have never been used in the 4 years since they have been added? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
