linux-kernel - Re: Why set .suppress_bind_attrs even though .remove() implemented?

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: <20241017093040.k6pefhmfdmw4nicz@thinkpad>
Date: Thu, 17 Oct 2024 15:00:40 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Johan Hovold <johan@...nel.org>, Bjorn Helgaas <helgaas@...nel.org>,
	Pali Rohár <pali@...nel.org>,
	Johan Hovold <johan+linaro@...nel.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Xiaowei Song <songxiaowei@...ilicon.com>,
	Binghui Wang <wangbinghui@...ilicon.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Ryder Lee <ryder.lee@...iatek.com>,
	Jianjun Wang <jianjun.wang@...iatek.com>, linux-pci@...r.kernel.org,
	Krzysztof Wilczyński <kw@...ux.com>,
	Ley Foon Tan <ley.foon.tan@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: Why set .suppress_bind_attrs even though .remove() implemented?

On Thu, Oct 17, 2024 at 09:48:50AM +0100, Marc Zyngier wrote:
> On Thu, 17 Oct 2024 09:25:26 +0100,
> Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org> wrote:
> > 
> > On Thu, Oct 17, 2024 at 08:50:11AM +0100, Marc Zyngier wrote:
> > > On Thu, 17 Oct 2024 06:23:35 +0100,
> > > Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org> wrote:
> > > > 
> > > > So can we proceed with the series making Qcom driver modular?
> > > 
> > > Who is volunteering to fix the drivers that will invariably explode
> > > once we allow this?
> > > 
> > 
> > Why should anyone volunteer first up? If the issue gets reported for a driver
> > blowing up, then the driver has to be fixed by the maintainer or someone, just
> > like any other bug.
> 
> You are introducing a new behaviour, and decide that it is fair game
> to delegate the problems *you* introduced to someone else?
>

You are getting it completely wrong. I'm not delegating any issues. If the so
called *new* behavior in the controller driver uncovers the bug in a client
driver, then that is not called *delegating*.

> Maybe you should reconsider what it means to be a *responsible*
> maintainer.
> 

Sure, by not providing a development option useful to the users envisioning
issues that may not happen at all.

Even if any issue reported for the platform I'm maintaining, I am willing to put
in the efforts to fix them.

> > From reading the thread, the major concern was disposing the IRQs before
> > removing the domain and that is now taken care of. If you are worrying about a
> > specific issue, please say so.
> 
> That concern still exists, and I haven't seen a *consistent* approach
> encompassing all of the PCI controllers. What I've seen is a bunch of
> point hacks addressing a local issue on a particular implementation.
> 

Again, please be specific about your concern so that someone could try to
address them. Right now all I'm hearing is, "hey don't do this, else
something may blow up".

> I don't think that's the correct approach, but hey, what do I
> understand about interrupts and kernel maintenance?
> 

I'd like to quote the message in your signature here: "Without deviation from
the norm, progress is not possible".

> > 
> > As a Qcom PCIe driver maintainer, I'd like to provide users/developers the
> > flexibility to remove the driver for development purposes.
> 
> Sure, whatever.
>

Thanks!

- Mani

-- 
மணிவண்ணன் சதாசிவம்