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] [day] [month] [year] [list]
Message-ID: <YtFROAbEJXfprB+y@kroah.com>
Date:   Fri, 15 Jul 2022 13:36:24 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Matt Hsiao <matt.hsiao@....com>
Cc:     linux-kernel@...r.kernel.org, arnd@...db.de, jerry.hoemann@....com,
        scott.norton@....com, camille.lu@....com, geoffrey.ndu@....com,
        gustavo.knuppe@....com
Subject: Re: [PATCH v2 1/1] misc: hpilo: switch .{read,write} ops to
 .{read,write}_iter

On Fri, Jul 15, 2022 at 04:55:57PM +0800, Matt Hsiao wrote:
> On Wed, Jul 13, 2022 at 08:28:24PM +0200, Greg KH wrote:
> > But my main question is I have no idea what the changelog means here.
> > What is a "dependent driver"?  What does "exclusive" mean here?  What is
> > a iter variant?
> 
> There is an out-of-box driver which is not in the upstream kernel yet
> that uses kernel_{read,write} to access the hpilo driver for talking
> to the iLO ASIC. Before commit 4d03e3cc59828c82ee89 ("fs: don't allow kernel
> reads and writes without iter ops"), kernel_{read,write} would call the
> .{read,write} file ops that hpilo already implemented, so there was no problem;
> But after that commit, kernel_{read,write} would only allow the .{read,write}_iter
> file ops, and disallowed the coexistence of .{read,write} file ops. Accessing
> hpilo now fails since it does not have the .{read,write}_iter file ops. To make it
> work, this patch implements the .{read,write}_iter file ops and removed the
> .{read,write} ones.

For obvious reasons, we can not take any changes for any out-of-tree
code.  Nor would you ever want me to do so.

So we can't take this, sorry.  Please work with your management to get
the drivers upstream and then we will be glad to take these types of
changes, as they well know the price they have to pay to have
out-of-tree code.

Also, your management knows we can't take changes for out-of-tree code.
They know better than to put you into this uncomfortable position.  This
is on them, not you, to resolve.  I suggest you have a stern talking to
with them as they are at fault here.

good luck!

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ