From: ebiederm@xmission•com (Eric W. Biederman)
To: James Bottomley <James.Bottomley@HansenPartnership•com>
Cc: David Miller <davem@davemloft•net>,
netdev@vger•kernel.org, James.Smart@Emulex•Com,
linux-scsi@vger•kernel.org
Subject: Re: [PATCH] scsi_netlink: Remove dead and buggy code
Date: Tue, 11 Sep 2012 15:40:08 -0700 [thread overview]
Message-ID: <878vcggp4n.fsf@xmission.com> (raw)
In-Reply-To: <1347314879.3038.74.camel@dabdike.int.hansenpartnership.com> (James Bottomley's message of "Mon, 10 Sep 2012 23:07:59 +0100")
James Bottomley <James.Bottomley@HansenPartnership•com> writes:
> On Mon, 2012-09-10 at 15:07 -0400, David Miller wrote:
>> From: ebiederm@xmission•com (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 <James.Bottomley@parallels•com>
>> > Cc: James Smart <James.Smart@Emulex•Com>
>> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission•com>
>>
>> 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
next prev parent reply other threads:[~2012-09-11 22:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 22:39 [PATCH] scsi_netlink: Remove dead and buggy code Eric W. Biederman
2012-09-08 22:51 ` David Miller
2012-09-10 19:07 ` David Miller
2012-09-10 22:07 ` James Bottomley
2012-09-11 22:40 ` Eric W. Biederman [this message]
2012-09-11 22:48 ` David Miller
2012-09-13 20:24 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878vcggp4n.fsf@xmission.com \
--to=ebiederm@xmission$(echo .)com \
--cc=James.Bottomley@HansenPartnership$(echo .)com \
--cc=James.Smart@Emulex$(echo .)Com \
--cc=davem@davemloft$(echo .)net \
--cc=linux-scsi@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox