Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 15 Sep 2022 16:05:17 +0200
From:   Harald Welte <laforge@gnumonks.org>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Hyunwoo Kim <imv4bel@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Ilpo =?iso-8859-1?Q?J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>,
        linux-kernel@vger.kernel.org,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        Paul Fulghum <paulkf@microgate.com>, akpm@osdl.org,
        Lubomir Rintel <lkundrak@v3.sk>
Subject: Re: [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl()
Message-ID: <YyMxHRXUTft4bG28@nataraja>
References: <20220913052020.GA85241@ubuntu>
 <a8a9fd74-4ee5-4619-8492-be7139e6d48e@www.fastmail.com>
 <20220915020834.GA110086@ubuntu>
 <f41c2765-80e0-48bc-b1e4-8cfd3230fd4a@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f41c2765-80e0-48bc-b1e4-8cfd3230fd4a@www.fastmail.com>
Precedence: bulk

Hi Arnd,

On Thu, Sep 15, 2022 at 09:35:51AM +0200, Arnd Bergmann wrote:
> There is a good chance that we can remove both now, along with the
> synclink_cs. The scr24x driver is from 2016, but of course the
> hardware is much older. The cm4040/cm4000 drivers are from 2005.
> My guess is that the hardware still exists in actively used systems,
> but none of them get upgraded to modern kernels any more.

It is probably true.  But the same argument can be made about all of the
PCMCIA drivers.  It's been a long time since any new mass-market hardware
with PCMCIA slots has been produced.  Even if you count in the (non-express)
cardbus, the same argument holds true.

I personally haven't used any of those cm4000/cm4040 in ages.  But what
particularly the last decade of my professional career has taught me:
There are typically always more users of legacy tech out there than you
would imagine.  The question is whether those users are relevant enough
for today's kernel maintainers to care.  This isn't meant to sound
bitter - I'm just stating facts.  It can be a valid "developer resource
economic" decision to not care.

Regards,
	Harald

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)