netdev - Re: [PATCH net-next V4 00/12] net/mlx5: ConnectX-4 100G Ethernet driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ3xEMiteyRsGuNQoQYiiZKeWkpjQE8WcJdQfWyxntJ9bjYXcw@mail.gmail.com>
Date:	Mon, 25 May 2015 22:07:23 +0300
From:	Or Gerlitz <gerlitz.or@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev <netdev@...r.kernel.org>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Tal Alon <talal@...lanox.com>,
	Achiad Shochat <achiad@...lanox.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Amir Vadai <amirv@...lanox.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Tom Herbert <tom@...bertland.com>,
	Jiří Pírko <jiri@...nulli.us>,
	Benjamin Poirier <bpoirier@...e.de>,
	Neil Horman <nhorman@...driver.com>
Subject: Re: [PATCH net-next V4 00/12] net/mlx5: ConnectX-4 100G Ethernet driver

On Wed, May 20, 2015 at 5:17 PM, Amir Vadai <amirv@...lanox.com> wrote:
> On Tue, May 19, 2015 at 7:41 PM, David Miller <davem@...emloft.net> wrote:
>> From: Amir Vadai <amirv@...lanox.com>
>> Date: Tue, 19 May 2015 12:25:12 +0300
>>
>>> On Sun, May 17, 2015 at 8:05 PM, David Miller <davem@...emloft.net> wrote:
>>>> From: Amir Vadai <amirv@...lanox.com>
>>>> Date: Sun, 17 May 2015 16:02:11 +0300
>>>>
>>>>> We didn't get a response yet regarding your comment about the irq
>>>>> renaming [3].
>>>>
>>>> Well then, please hold off on resubmissions of this series until you
>>>> do get a response and that issue is firmly resolved.
>>> Hi,
>>>
>>> I don't mean to push you, I only want to understand what is expected
>>> from me and what are the next steps:
>>> How will the issue be resolved? Do you plan to answer my question [1]
>>> from last week, and just too busy right now or something like that?
>>
>> I have not seen any response to me explaining why it's ok to change
>> the IRQ name strings in the context where this will occur.
>>
>> Once you explain that, we can make forward progress, but only at that
>> point.
>
> Hi Dave,
>
> Just to put us back on the same page, repeating a bit the previous chapters..
>
> You wrote [1] that if we change these names after the request_irq() call(s), the
> new name string will not propagate to /proc/interrupts output.
>
> So, indeed, request_irq() is called when the driver is loaded (and we
> don't know yet if the port types are Infiniband or Ethernet). Only later
> on, we rename the name when the Ethernet interface is up and we know
> its name.
>
> Fact is that the new name does propagate to /proc/interrupts.
>
> Also, looking in the code, I don't see a reason why shouldn't it
> be properly updated. When calling request_irq(), the name argument
> is not copied, but irq_desc->action->name points to it. This same pointer
> is being used by show_interrupts() when /proc/interrupts is shown.
>
> All in all, unless I somehow missed your precise question or I didn't
> explain myself clearly, I don't see what is still missing in my reply,
> can you please shed some light?
>
> What I did find is that the /proc/irq/N/handler directory name
> which is a copy of the original action->name doesn't change. However
> AFAIK, this directory isn't being used anywhere in the kernel.
>
> [1] - http://www.spinics.net/lists/netdev/msg328444.html


Hi Dave,

Going over this thread, Amir's response to your comments make sense to
me -- could you please
let us know if you're convinced... and if not, where his arguments break?

I also copied some more folks and will love it if more people will
provide their opinion
on the matter.

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