[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201212132000.36261.vitas@nppfactor.kiev.ua>
Date: Thu, 13 Dec 2012 20:00:36 +0200
From: Vitalii Demianets <vitas@...factor.kiev.ua>
To: "Hans J. Koch" <hjk@...sjkoch.de>
Cc: Cong Ding <dinggnu@...il.com>, linux-kernel@...r.kernel.org,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2] drivers/uio/uio_pdrv_genirq.c: Fix memory freeing issues
On Thursday 13 December 2012 19:34:00 Hans J. Koch wrote:
> On Thu, Dec 13, 2012 at 07:23:21PM +0200, Vitalii Demianets wrote:
> > On Thursday 13 December 2012 19:11:09 Hans J. Koch wrote:
> > > On Tue, Dec 11, 2012 at 12:47:35PM +0200, Vitalii Demianets wrote:
> > > > Please, review the v3 of "Fix memory freeing issues" patch (first in
> > > > the series I posted yesterday) and ignore the second, as we haven't
> > > > agreed on it.
> > >
> > > I can't find a v3. Please resend it.
> >
> > I've posted v3 as a [PATCH 1/2 v3] in series:
> > http://www.spinics.net/lists/kernel/msg1450101.html
> >
> > You were CC-ed. If for some reason you didn't get it in your mailbox,
> > I'll resend.
>
> OK, found it, sorry. I ignored that one because it does the same
> flag-testing stuff. It is unnecessary and only tries to fix userspace
> stupidity in the kernel. I won't buy that one, and I already gave an
> explanation why. I won't take it just because you disagree with my opinion.
>
Hans, it keeps flag-testing code in place and does not change it. It keeps
previous behaviour. I divided the patch in two parts and posted it in series
specifically for that purpose, first patch in series does only memory-related
stuff.
It happens so that it needs another flag (UIO_INFO_ALLOCED) to do that
memory-related stuff well. That's the only reason I gave the name to the
already existing previously unnamed flag (bit 0, now UIO_IRQ_DISABLED).
Again, the "Fix memory freeing issues" patch fixes only what it says on the
tin: memory freeing issues. All flag-manipulation changes belong to the patch
2/2 in the series, which you could soundly reject, because we disagree on
that matter.
Keeping this flag-testing stuff as it was doesn't do any harm. Are you saying
that you reject memory-related patch only because it doesn't change something
else, totally unrelated?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists