A semantic patch has no access to comments. The only thing I can see to
do is to use python to interact with some external tools. For example,
you could write some code to collect the comments in a file and the lines
on which they occur, and then get the comment that most closely precedes
the start of the function.
julia
> A semantic patch has no access to comments.
Thanks for your acknowledgement of the current situation.
> The only thing I can see to do is to use python to interact with some external tools.
I see more software development possibilities.
* Advanced data processing for source code comments
https://github.com/coccinelle/coccinelle/issues/57
* Add a metavariable for the handling of source code
https://github.com/coccinelle/coccinelle/issues/140
Regards,
Markus
Hi!
> A semantic patch has no access to comments. The only thing I can see to
> do is to use python to interact with some external tools. For example,
> you could write some code to collect the comments in a file and the lines
> on which they occur, and then get the comment that most closely precedes
> the start of the function.
How dangerous is missing of_node_put? AFAICT it will only result into
very small, one-time memory leak, right?
Could we make sure these patches are _not_ going to stable? Leaking
few bytes once per boot is not really a serious bug.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 20 May 2019, Pavel Machek wrote:
> Hi!
>
> > A semantic patch has no access to comments. The only thing I can see to
> > do is to use python to interact with some external tools. For example,
> > you could write some code to collect the comments in a file and the lines
> > on which they occur, and then get the comment that most closely precedes
> > the start of the function.
>
> How dangerous is missing of_node_put? AFAICT it will only result into
> very small, one-time memory leak, right?
>
> Could we make sure these patches are _not_ going to stable? Leaking
> few bytes once per boot is not really a serious bug.
Sasha,
Probably patches that add only of_node_put should not be auto selected for
stable.
julia
On Mon, May 20, 2019 at 11:52:37AM +0200, Julia Lawall wrote:
>
>
>On Mon, 20 May 2019, Pavel Machek wrote:
>
>> Hi!
>>
>> > A semantic patch has no access to comments. The only thing I can see to
>> > do is to use python to interact with some external tools. For example,
>> > you could write some code to collect the comments in a file and the lines
>> > on which they occur, and then get the comment that most closely precedes
>> > the start of the function.
>>
>> How dangerous is missing of_node_put? AFAICT it will only result into
>> very small, one-time memory leak, right?
>>
>> Could we make sure these patches are _not_ going to stable? Leaking
>> few bytes once per boot is not really a serious bug.
>
>Sasha,
>
>Probably patches that add only of_node_put should not be auto selected for
>stable.
I can filter them out, but those are fixes, right? Why are we concerned
about them making it into -stable?
--
Thanks,
Sasha
On Mon, 20 May 2019, Sasha Levin wrote:
> On Mon, May 20, 2019 at 11:52:37AM +0200, Julia Lawall wrote:
> >
> >
> > On Mon, 20 May 2019, Pavel Machek wrote:
> >
> > > Hi!
> > >
> > > > A semantic patch has no access to comments. The only thing I can see to
> > > > do is to use python to interact with some external tools. For example,
> > > > you could write some code to collect the comments in a file and the
> > > lines
> > > > on which they occur, and then get the comment that most closely precedes
> > > > the start of the function.
> > >
> > > How dangerous is missing of_node_put? AFAICT it will only result into
> > > very small, one-time memory leak, right?
> > >
> > > Could we make sure these patches are _not_ going to stable? Leaking
> > > few bytes once per boot is not really a serious bug.
> >
> > Sasha,
> >
> > Probably patches that add only of_node_put should not be auto selected for
> > stable.
>
> I can filter them out, but those are fixes, right? Why are we concerned
> about them making it into -stable?
One of them may have introduced a crash. If there is a bad reference
count manipulation elsewhere, then fixing one could cause a later
incorrect one to make a double free.
On the other hand, I don't know if the one that seemed to cause a crash
really caused a crash. It was detected by syzkaller, and it is also
possible that git bisect ended up at the wrong place.
In any case, forgetting an of_node_put will normally just waste a little
memory, so probably stable kernels don't care.
julia
> On the other hand, I don't know if the one that seemed to cause a crash
> really caused a crash. It was detected by syzkaller, and it is also
> possible that git bisect ended up at the wrong place.
Do you refer to any known bug report here?
> In any case, forgetting an of_node_put will normally just waste a little
> memory, so probably stable kernels don't care.
Will it be nice to achieve better exception handling also for these
software versions over time?
Regards,
Markus