From: Takashi Iwai <tiwai@suse.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Mateusz Guzik <mguzik@redhat.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 16:47:11 +0200 [thread overview]
Message-ID: <s5h38gw9or4.wl%tiwai@suse.de> (raw)
In-Reply-To: <20140427224425.GQ26890@mwanda>
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.
Takashi
next prev parent reply other threads:[~2014-04-29 14:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-26 17:09 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 [this message]
2014-04-29 15:02 ` Dan Carpenter
2014-04-29 15:26 ` Mateusz Guzik
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=s5h38gw9or4.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--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=mguzik@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®