[lvc-project] [PATCH 6.1 v2 3/3] scsi: aic79xx: check for non-NULL scb in ahd_linux_queue_abort_cmd

[Boris Belyavtsev]

On Fri Apr 25, 2025 at 11:51 PM +07, Fedor Pchelkin wrote:
> On Fri, 25. Apr 09:52, Boris Belyavtsev wrote:
> > Также пришло письмо в ответ на патч отправленный в linux-scsi от
> > "James Bottomley" <James.Bottomley at HansenPartnership.com>
> >
> > On Mon Apr 21, 2025 at 7:12 PM +07, James Bottomley wrote:
> > > On Mon, 2025-04-21 at 15:16 +0700, Boris Belyavtsev wrote:
> > > > Add non-NULL checks for ahd_lookup_scb return value.
> > > >
> > > > scb could be NULL if faulty hardware return certain incorrect values
> > > > to the driver.
> > >
> > > It's a general principle that we trust values coming from the card ...
> > > you are, after all, trusting it with your data.  If there's a fault in
> > > the way the card is operating, we can work around that, so if you have
> > > a card which is producing these NULLs, can you provide details so we
> > > can investigate?
> > >
> > > Regards,
> > >
> > > James
>
> Во-первых, отвечать и реагировать на вопросы сообщества конечно стоит.
> Иначе в отсутствие фидбэка они могут перестать реагировать на отправителя
> в дальнейшем. Здесь Вы правы, что ответить надо.
>

Получил следующее письмо от мэйнтейнера:

>On Mon, 2025-04-28 at 11:32 +0700, Boris Belyavtsev wrote:
>> On Mon Apr 21, 2025 at 7:12 PM +07, James Bottomley wrote:
>> > On Mon, 2025-04-21 at 15:16 +0700, Boris Belyavtsev wrote:
>> > > Add non-NULL checks for ahd_lookup_scb return value.
>> > >
>> > > scb could be NULL if faulty hardware return certain incorrect
>> > > values to the driver.
>> >
>> > It's a general principle that we trust values coming from the card
>> > ... you are, after all, trusting it with your data.  If there's a
>> > fault in the way the card is operating, we can work around that, so
>> > if you have a card which is producing these NULLs, can you provide
>> > details so we can investigate?
>> >
>> > Regards,
>> >
>> > James
>>
>> Well, to be honest, I do not have such a device/card which would
>> represent the problem. These checks are more about defensive
>> programming (in case of an accident fault in a card for example).
>
>We don't program defensively against adapters: they're part of our
>trust domain.  We only program defensively against input from untrusted
>domains (like user space).  The problem with defensively programming
>drivers was nicely demonstrated by the driver hardening project:
>
>https://lore.kernel.org/all/20230119170633.40944-1-alexander.shishkin@linux.intel.com/
>
>In that there are so many ways that drivers could be used to attack the
>OS, defending against all of them would dramatically impact the fast
>path.  Which is also the reason we don't imagine card faults and then
>program for them without first finding the problem in the field.
>
>Regards,
>
>James

Думаю в таком случае предупреждение разметки стоит пересмотреть в
сторону Won't Fix.