From: Mateusz Guzik <mguzik@redhat.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
gregkh@linuxfoundation.org, devel@driverdev.osuosl.org,
Laurent Navet <laurent.navet@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: line6: fix possible overrun
Date: Tue, 29 Apr 2014 17:26:17 +0200 [thread overview]
Message-ID: <20140429152616.GA2316@mguzik.redhat.com> (raw)
In-Reply-To: <s5h38gw9or4.wl%tiwai@suse.de>
On Tue, Apr 29, 2014 at 04:47:11PM +0200, Takashi Iwai wrote:
> At Mon, 28 Apr 2014 01:44:25 +0300,
> Dan Carpenter wrote:
> >
> > On Sun, Apr 27, 2014 at 10:00:43PM +0200, Mateusz Guzik wrote:
> > > > > and a WARN_ON + -EINVAL in line6_init_audio to catch future
> > > > > offenders.
> > > >
> > > > Returning -EINVAL is a bad idea because it would break the driver
> > > > completely and make it unusable.
> > > >
> > >
> > > Well I would vote for returning the error anyway.
> >
> > I'm trying to be polite, but you are talking about adding regressions
> > deliberately...
> >
> > It's very rare for people to deliberately add regressions to the kernel.
> > I have only seen it one time before.
>
> I don't think Dan would be against returning -EINVAL if all the
> offender codes have been fixed (e.g. truncating strings to fit with
> the fixed arrays) at first. Then it'd be a good help to catch any
> future bugs. But, having -EINVAL without fixing the caller side means
> essentially that you're introducing the breakage intentionally
> although you know it certainly breaks, which is obviously bad.
>
>
We clearly have a serious miscommunication here (and apparently it
started with me not addressing the concern of complete driver breakage).
line6_init_audio consumers have to be fixed first, no doubt about that.
I was only commenting on catching *future* offenders, which I thought
would implictly mean *afterwards*.
With that in mind it would seem we are in agreement after all. :-)
As far getting this done maybe OP is interested.
--
Mateusz Guzik
next prev parent reply other threads:[~2014-04-29 15:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-26 17:09 [PATCH] staging: line6: fix possible overrun Laurent Navet
2014-04-26 20:47 ` Mateusz Guzik
2014-04-26 21:36 ` Dan Carpenter
2014-04-26 21:59 ` Mateusz Guzik
2014-04-27 17:39 ` Dan Carpenter
2014-04-27 19:05 ` Laurent Navet
2014-04-27 20:00 ` Mateusz Guzik
2014-04-27 22:44 ` Dan Carpenter
2014-04-29 14:47 ` Takashi Iwai
2014-04-29 15:02 ` Dan Carpenter
2014-04-29 15:26 ` Mateusz Guzik [this message]
2014-04-29 17:28 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140429152616.GA2316@mguzik.redhat.com \
--to=mguzik@redhat.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=laurent.navet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.