[bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Ingo Molnar]

randconfig testing found a netfilter build failure in latest -git:

  net/netfilter/nf_conntrack_sip.c: In function 'set_expected_rtp_rtcp':
  net/netfilter/nf_conntrack_sip.c:786: error: 'struct nf_conntrack_expect' has no member named 'saved_ip'

  http://redhat.com/~mingo/misc/config-Sat_Apr_19_11_37_02_CEST_2008.bad

disabling CONFIG_NF_CONNTRACK_SIP works it around.

btw., i found no thread to reply to on lkml or elsewhere - arent all git 
pull requests supposed to be Cc:-ed to lkml, with shortlog included?

	Ingo

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Sat, 19 Apr 2008 12:00:35 +0200

> btw., i found no thread to reply to on lkml or elsewhere - arent all git 
> pull requests supposed to be Cc:-ed to lkml, with shortlog included?

I have never once done this even going all the way back to the BK
days.

I always send my pull requests directly to Linus, CC:'ing Andrew.

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Sat, 19 Apr 2008 12:00:35 +0200
> 
> > btw., i found no thread to reply to on lkml or elsewhere - arent all 
> > git pull requests supposed to be Cc:-ed to lkml, with shortlog 
> > included?
> 
> I have never once done this even going all the way back to the BK 
> days.

do you find this practice of private pull requests important? If not, 
would it be difficult to Cc: lkml to routine pull requests?

> I always send my pull requests directly to Linus, CC:'ing Andrew.

that makes bugs harder to report and makes the flow of patches harder to 
follow as well. Often (like in this case) i see it when a bug comes in 
via a specific group of commits but i have no time to do a bisection. In 
that case i'd like to report it to that pull request so i'd like to 
reply to that pull on lkml.

But in this case i first did an unsuccessful full-text search on lkml, 
then i also opened up netdev and did a full text search there too to 
find the originator pull request or the patches but the search turned up 
nothing. As the number of subsystems increases, i suspect you agree with 
me that this does not scale very well for bug reporters, correct?

i'm convinced that testers and bug reporters are the scarce resource 
these days, not patch integrators and not maintainers which was the 
scarce resource 3-4 years ago, before Git and before BK. It is testing 
(and review) capacity that limits the growth of Linux today, not patch 
writing and patch integration capacity.

	Ingo

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Sat, 19 Apr 2008 12:39:42 +0200

I knew you were going to make a stink about this, and frankly Ingo I'm
starting to get extremely irritated about your persistant nagging
about how people should do this or that wrt. kernel development.

I seem to see a lot of it because 1) I don't think pushing everything
to lkml is the answer to everything and 2) I think the trees like -mm
and linux-next take care of the scalability issues of watching the
state of trees that will be merged to Linus in the future.

You haven't cared about how I push my trees to Linus for years, why is
it a problem all of a sudden?

Different people operate differently, and might have alternate
approaches to insuring quality and smooth merging of the changes they
manage.  The only thing that really matters is that the people who
push directly to Linus are trusted by him, and they won't disappear
right after he pulls their changes in.

You got a bug fix in 5 minutes after sending your email to the lists,
and since you sent it to lkml anybody can find it, so I don't see what
the big deal is.

> do you find this practice of private pull requests important? If not, 
> would it be difficult to Cc: lkml to routine pull requests?

Ingo, I don't tell you how to effectively do your job with x86
development.  So why don't we leave it at that, ok?

> > I always send my pull requests directly to Linus, CC:'ing Andrew.
> 
> that makes bugs harder to report and makes the flow of patches harder to 
> follow as well. Often (like in this case) i see it when a bug comes in 
> via a specific group of commits but i have no time to do a bisection. In 
> that case i'd like to report it to that pull request so i'd like to 
> reply to that pull on lkml.

Ingo, get off your high holy horse already.  It is your opinion that
bugs are harder to report.  You got a bug fix in 5 minutes by sending
it the people in the group of singoffs and CC:'ing lkml.  What the
heck more do you want? :-/

The way you see as the ideal isn't something you can just start
demanding of other people because it doesn't work optimally for you.

All of this networking stuff has been in linux-next and -mm for
several months.  And frankly it doesn't help anyone to spam ~5000 lkml
subscribers with a 128K sized merge request, which is how big this one
was.  In fact, as list owner for all of the vger lists, I'd probably
be processing a bunch of bounces as a result of such a posting.

If you want to start running your randconfig machinery on the
linux-next tree and -mm, that would be a great contribution for
keeping build regressions down to a healthy minimum before the merge
window opens up.

> As the number of subsystems increases, i suspect you agree with 
> me that this does not scale very well for bug reporters, correct?

That's why we have -mm and linux-next, to make it scale.

I'm not hiding anything, or operating in secrecy in an attempt to
thwart the productivity of other kernel developers.  My trees sync
daily into Andrew and Stephen Rothwell's trees, and every networking
patch goes through netdev.  Bugs aren't hard to report, send them
to the patch author and signoff emails, CC:'ing lkml and any other
list as you deem appropriate.

Ingo, I can't have a healthy relationship with you a fellow kernel
developer if every interaction we have with eachother these days is
about how you want me to change how I do my work.

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Sat, 19 Apr 2008 12:39:42 +0200
> 
> I knew you were going to make a stink about this, and frankly Ingo I'm 
> starting to get extremely irritated about your persistant nagging 
> about how people should do this or that wrt. kernel development.
>
> I seem to see a lot of it because 1) I don't think pushing everything 
> to lkml is the answer to everything and 2) I think the trees like -mm 
> and linux-next take care of the scalability issues of watching the 
> state of trees that will be merged to Linus in the future.

And i'd like to make one thing really clear, before we discuss anything 
else. You seem to imply in your mail that i'm somehow picking on you. 
I'm not - i try to be as unbiased in terms of picking subsystems that i 
find bugs in as it gets: it's randconfig builds/bootups that selects the 
test target, not me. I'd be the happiest camper if these discussions 
werent happening at all. I'm not out here looking for bugs. Look at 
lkml, i reported the bugs in the order and frequency as they were found 
by the qa scripts.

Fact is that for the third straight day i cannot do meaningful overnight 
testing of my trees because -git keeps spewing out build failures.

( And i cannot just change the QA scripts to skip over networking build
  bugs. My build system _runs on the tested kernel_, to prove that the 
  kernel is reasonably self-hosting and to prove that the 
  user/developer, even if a kernel was buggy, would be able to download 
  a new kernel over the network and would be able to build a new kernel. 
  So if there's any build failure the whole test stops and i need to see 
  the exact nature of the failure myself. I found a handful of bugs 
  where there was no real build bug but a bug in the target kernel made 
  the build fail. Just two weeks ago i had a DMA bug that showed up as a 
  sporadic build error. )

Let me give you an example, for code neither of us maintains, maybe that 
works better as an argument. I dont remember the last time when i 
triggered _any_ VFS bug (build or runtime bug) - and it's a subsystem 
that is larger and even more central one than networking. The VFS rate 
of change (# of commits and diffstat) is comparably high as well:

  $ git-rev-list v2.6.24..v2.6.25 fs/ | wc -l
  929
  $ git-diff v2.6.24..v2.6.25 fs/  | diffstat | tail -1
  624 files changed, 27449 insertions(+), 16385 deletions(-)


  $ git-rev-list v2.6.24..v2.6.25 net/ | wc -l
  1389
  $ git-diff v2.6.24..v2.6.25 net/  | diffstat | tail -1
  654 files changed, 43514 insertions(+), 23357 deletions(-)

sure, there are crutial differences between the two codebases - but the 
difference seems striking to me, in actual hands-on testing. Why is 
that? Are the filesystem folks different due to the nature of their 
code?

> You haven't cared about how I push my trees to Linus for years, why is 
> it a problem all of a sudden?

the answer is simple, and it has nothing to do with you or with 
networking at all: i'm maintaining about 10 times more code (and more 
commits) than before. That means i'm signing off on more than 1000 
commits per release, and i'm exposed in a magnified way to other 
people's trees. And i still do what i did for the last 13 years of Linux 
kernel hacking: when i see a problem i either fix it or i complain about 
it so that it gets fixed. And when a problem stays unfixed i complain 
louder. And i do all that in a loop ;-)

and i'd like to remind you of the following unfixed v2.6.25 networking 
regression:

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10427
 Subject         : e1000e broke e1000
 Submitter       : Ingo Molnar <mingo@elte.hu>
 Date            : 2008-04-08 20:39 (13 days old)
 References      : http://lkml.org/lkml/2008/4/8/256
 Patch           : http://bugzilla.kernel.org/attachment.cgi?id=15704&amp;action=view

You pushed a stream of last-minute networking fixes upstream even in the 
very last minutes of v2.6.25 but this one was either forgotten or not 
deemed important enough. There was no followup i could see, the 
discusssion just went dead with no resolution that i can see.

> Different people operate differently, and might have alternate 
> approaches to insuring quality and smooth merging of the changes they 
> manage.  The only thing that really matters is that the people who 
> push directly to Linus are trusted by him, and they won't disappear 
> right after he pulls their changes in.
> 
> You got a bug fix in 5 minutes after sending your email to the lists, 
> and since you sent it to lkml anybody can find it, so I don't see what 
> the big deal is.

for the last 3 days my own automated bug finding capacity is at 10% of 
its normal throughput (it booted only 200 kernels, instead of 2000 
kernels) - which is OK in early phases of the merge window, but you seem 
to deny that i have any standing to argue development process issues.
:-/ Who has standing to argue with you in those issues, only Linus?

	Ingo

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 21 Apr 2008 10:22:54 +0200

> * David Miller <davem@davemloft.net> wrote:
> 
> > You haven't cared about how I push my trees to Linus for years, why is 
> > it a problem all of a sudden?
> 
> the answer is simple, and it has nothing to do with you or with 
> networking at all: i'm maintaining about 10 times more code (and more 
> commits) than before.

Then, I can only conclude what several others have also concluded, that
you've taken on x86 maintainence purely so that you can berate other
subsystem maintainers who don't do things up to your specifications
and standards.

And frankly Ingo, that sucks.

Instead of discussing things with people, you get up every morning and
shoot off your randconfig nuclear bombs at your targets.  It's what
you've done all weekend long and it's very much NOT appreciated.

The build failure knowledge is appreciated, however the reason you are
reporting them is not.  Why do we need to know that your automated
tools have found 5 networking build failures "so far" over the
weekend?  That number is relative to what, exactly?  It has no purpose
other as a tool that lets you say "networking broke the build,
substantially, see?"  And for the record most of what you've
discovered are extreme edge cases that our Kbuild language machinery
doesn't handle very well.

Now, as a result of doing x86 maintainence, you can say "see how well
I maintain a subsystem" and the implication is that the way other
people do their work results in a vastly inferier result.

And frankly Ingo, that also sucks.

All the while you have your randconfig machinery to "prove" things,
which allows you to bypass any suspicion of targetting anyone on
ideological grounds.

If you really cared, you would run your randconfig system on, for
example, the linux-next and -mm trees, which I've specifically
suggested and you've specifically ignored.  And there is no
coincidence to that.

You'd rather not do it, and the reason is that doing so would actually
help Linux kernel development as a whole rather than serve your
specific political and ideological goals.

And that, Ingo, really sucks.

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Mon, 21 Apr 2008 10:22:54 +0200
> 
> > * David Miller <davem@davemloft.net> wrote:
> > 
> > > You haven't cared about how I push my trees to Linus for years, 
> > > why is it a problem all of a sudden?
> > 
> > the answer is simple, and it has nothing to do with you or with 
> > networking at all: i'm maintaining about 10 times more code (and 
> > more commits) than before.

<complete quote>
> > That means i'm signing off on more than 1000 commits per release, 
> > and i'm exposed in a magnified way to other people's trees. [...]
</complete quote>

> Then, I can only conclude what several others have also concluded, 
> that you've taken on x86 maintainence purely so that you can berate 
> other subsystem maintainers who don't do things up to your 
> specifications and standards.
> 
> And frankly Ingo, that sucks.
> 
> Instead of discussing things with people, you get up every morning and 
> shoot off your randconfig nuclear bombs at your targets.  It's what 
> you've done all weekend long and it's very much NOT appreciated.

David, your argument is getting rather surreal and unjust.

in case you havent been following us on lkml lately, we've been doing 
these randconfig tests (and have been reporting failures) for the last 
6+ months almost non-stop. Initially it was rather hard to do - i 
carried dozens of patches at times to keep the test humping along.

That shrunk within 1-2 months and these days this test generally works 
fine day over day, night over night - with the merge window being an 
(expected) small hickup. There's nothing new about it and if there's 
anything nuclear here it's your accusations :-(

in hindsight i'm particularly happy that the test creates a random 
sample because that way i can have no influence _at all_ about what kind 
of bug gets found, so it is plain obvious that:

 - its not about berating other maintainers
 - its not about proving i do a better job

if you got 5 networking bugreports from me in short succession that is 
simply so because they triggered in such short succession!

Also, because it's a random sample, we can make reliable observations 
about the bug patterns - like it or not. That is _good_, because it 
gives a metric without much (or any) subjective bias. Do you regard it 
inappropriate to make any observations about the patterns of bugs we 
find and report?

So IMO there's absolutely no objective reason for you to be upset about 
_me_ - i'm just running a test that generates random kernels and i 
report failures as i get them and observe patterns and annoyances while 
doing so.

And i dont even understand your argument that basing and testing our 
trees against latest -git is somehow wrong and that we should base our 
trees against linux-next or -mm - you dont base your trees against them 
either, and for similarly obvious reasons i suspect, right?

> The build failure knowledge is appreciated, however the reason you are 
> reporting them is not.  Why do we need to know that your automated 
> tools have found 5 networking build failures "so far" over the 
> weekend?  That number is relative to what, exactly?  [...]

My "so far" comment was based on the simple fact that these tests are 
running non-stop and are continuously finding new bugs - and that the 
last 5 bugs that triggered were networking. In my experience, if 5 build 
bugs trigger in relatively short succession in a random sample, in 2500 
new commits (out of which ~1000 are networking), then more might be 
there as well - just harder to trigger.

[ btw., today seems to be a better day finally: after excluding that
  minor SCTP complication from the test space, 116 kernels built and
  booted up fine in a row, so far. ]

	Ingo

Re: [bug] build failures, git trees

[Randy Dunlap]

On Mon, 21 Apr 2008 01:58:37 -0700 (PDT) David Miller wrote:

<deletia>

> If you really cared, you would run your randconfig system on, for
> example, the linux-next and -mm trees, which I've specifically
> suggested and you've specifically ignored.  And there is no
> coincidence to that.

I do randconfigs on -mm and linux-next.  I report most* of the
build problems ... and as far as I can tell, they are mostly
ignored (especially in linux-next).

*: I don't report Voyager/Visual WS/NUMA-Q build errors.
Maybe they will just disappear one day.
I also don't report drivers/media/ build errors. They are too easy
to reproduce.  :(

IMO having -mm and linux-next is a diluting factor+.  They dilute
both build and boot testing of the other one and of mainline
-rcs.  Yes, they have their purposes, but it would be Very Good
if we could get to the point of having -mm built on top of
linux-next (e.g.) instead of it just being a separate tree.

+: Yes, there are other diluting factors, like having over 100 git
trees that someone may potentially request testing of.

---
~Randy

Re: [bug] build failures, git trees

[David Miller]

From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 21 Apr 2008 09:26:48 -0700

> On Mon, 21 Apr 2008 01:58:37 -0700 (PDT) David Miller wrote:
> 
> <deletia>
> 
> > If you really cared, you would run your randconfig system on, for
> > example, the linux-next and -mm trees, which I've specifically
> > suggested and you've specifically ignored.  And there is no
> > coincidence to that.
> 
> I do randconfigs on -mm and linux-next.  I report most* of the
> build problems ... and as far as I can tell, they are mostly
> ignored (especially in linux-next).

If you reported them against networking, I can ensure you that I did
work to correct them.  And if I didn't it was an oversight.

So at least in that context, don't feel as if such efforts are wasted.

Thanks Randy.

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Patrick McHardy]

Ingo Molnar wrote:
> * David Miller <davem@davemloft.net> wrote:
> 
>> You got a bug fix in 5 minutes after sending your email to the lists, 
>> and since you sent it to lkml anybody can find it, so I don't see what 
>> the big deal is.
> 
> for the last 3 days my own automated bug finding capacity is at 10% of 
> its normal throughput (it booted only 200 kernels, instead of 2000 
> kernels) - which is OK in early phases of the merge window, but you seem 
> to deny that i have any standing to argue development process issues.


In my perception networking is not doing worse than other subsystems,
this (small) accumulation of build-bugs seems more like an unfortunate
coincidence caused by two people being sloppy during testing (me and
the LED guys).

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Ingo Molnar]

* Patrick McHardy <kaber@trash.net> wrote:

>> for the last 3 days my own automated bug finding capacity is at 10% 
>> of its normal throughput (it booted only 200 kernels, instead of 2000 
>> kernels) - which is OK in early phases of the merge window, but you 
>> seem to deny that i have any standing to argue development process 
>> issues.
>
> In my perception networking is not doing worse than other subsystems, 
> this (small) accumulation of build-bugs seems more like an unfortunate 
> coincidence caused by two people being sloppy during testing (me and 
> the LED guys).

nah, it's not doing worse at all and my comment was not really about the 
bug itself (bugs happen), but about the most efficient way to report 
that bug - which in hindsight is not an argument i should have gotten 
into. arch/x86 has at least this proportion of build bugs if not more. 
[and the scheduler is a 50 times smaller piece of code so it's not 
really comparable.]

btw., managed to test 755 random kernels today:

  #define UTS_VERSION "#755 SMP PREEMPT Mon Apr 21 21:12:52 CEST 2008"

with no runtime (or build) failure anywhere. [other than in freshly 
added x86.git or scheduler patches that is.]

	Ingo

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Jeff Garzik]

Ingo Molnar wrote:
> * David Miller <davem@davemloft.net> wrote:
> 
>> From: Ingo Molnar <mingo@elte.hu>
>> Date: Sat, 19 Apr 2008 12:00:35 +0200
>>
>>> btw., i found no thread to reply to on lkml or elsewhere - arent all 
>>> git pull requests supposed to be Cc:-ed to lkml, with shortlog 
>>> included?
>> I have never once done this even going all the way back to the BK 
>> days.
> 
> do you find this practice of private pull requests important? If not, 
> would it be difficult to Cc: lkml to routine pull requests?
> 
>> I always send my pull requests directly to Linus, CC:'ing Andrew.
> 
> that makes bugs harder to report and makes the flow of patches harder to 
> follow as well. Often (like in this case) i see it when a bug comes in 
> via a specific group of commits but i have no time to do a bisection. In 
> that case i'd like to report it to that pull request so i'd like to 
> reply to that pull on lkml.
> 
> But in this case i first did an unsuccessful full-text search on lkml, 
> then i also opened up netdev and did a full text search there too to 
> find the originator pull request or the patches but the search turned up 
> nothing. As the number of subsystems increases, i suspect you agree with 
> me that this does not scale very well for bug reporters, correct?

Well, 'git log [$file]' is even more scalable and precise, if committer 
(as well as author) info and patch flow info is what a tester or bug 
reporter seeks.

But it sounds like you are making an assumption about development 
/style/, then complaining when reality doesn't match that assumption.


> i'm convinced that testers and bug reporters are the scarce resource 
> these days, not patch integrators and not maintainers which was the 
> scarce resource 3-4 years ago, before Git and before BK. It is testing 
> (and review) capacity that limits the growth of Linux today, not patch 
> writing and patch integration capacity.

We're all for more bug reports and testing, but the link you are trying 
to draw is more than a little overblown.  I'm not convinced LKML's lack 
of davem pull request visibility is a problem source limiting the growth 
of Linux today...  That's a bit much.  :)

AFAICT you and davem have different development styles, he doesn't work 
the way you work, but the tone of your emails recently has been "if you 
do not fit my preferred development worldview, you are creating problems 
for Linux."  Witness not just this thread, but the LKML-vs-netdev 
discussions.

	Jeff

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Ingo Molnar]

* Jeff Garzik <jeff@garzik.org> wrote:

>> But in this case i first did an unsuccessful full-text search on 
>> lkml, then i also opened up netdev and did a full text search there 
>> too to find the originator pull request or the patches but the search 
>> turned up nothing. As the number of subsystems increases, i suspect 
>> you agree with me that this does not scale very well for bug 
>> reporters, correct?
>
> Well, 'git log [$file]' is even more scalable and precise, if 
> committer (as well as author) info and patch flow info is what a 
> tester or bug reporter seeks.

but the only information i had at that point was that 'something in that 
recent appearance of a large group of networking commits introduced the 
problem'. There was no commit log entry of even the merge.

> But it sounds like you are making an assumption about development 
> /style/, then complaining when reality doesn't match that assumption.

no. I simply failed to put this (trivial) bugreport into some sort of 
existing context of discussion, and made a brief and neutral(-looking) 
comment about that. Under no other development style could i have done 
that because the context was simply missing from the mailing lists.

I did not intend this to be a big deal comment. It was literally just 
this single side-question:

||  disabling CONFIG_NF_CONNTRACK_SIP works it around.
||
||  btw., i found no thread to reply to on lkml or elsewhere - arent all 
||  git pull requests supposed to be Cc:-ed to lkml, with shortlog 
||  included?

I was seriously surprised that large pull requests and shortlogs dont go 
to lkml. Perhaps some sort of negative sentiment was perceived in that 
single sentence of mine? If yes, how should i have expressed this 
comment otherwise?

and i mean, lost context of discussion happens all the time and i do it 
too - recently Andrew complained that ftrace commits were not on lkml 
and he was complaining rightfully. We dont notice it unless people 
mention it.

[ later on the tone of the discussion degenerated indeed. ]

	Ingo

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Herbert Xu]

Ingo Molnar <mingo@elte.hu> wrote:
>
> but the only information i had at that point was that 'something in that 
> recent appearance of a large group of networking commits introduced the 
> problem'. There was no commit log entry of even the merge.

It is human nature to blame someone/something when things go wrong.
It just happens that the lack of a merge request was the first you
tacked onto in this case :)

I don't think we can seriously argue that had there been a merge
request on lkml that these build issues would have somehow gone
away or resolved any sooner than they have been.  The fact is
with or without the merge request you would have realised that
network bug reports == davem :)

> no. I simply failed to put this (trivial) bugreport into some sort of 
> existing context of discussion, and made a brief and neutral(-looking) 
> comment about that. Under no other development style could i have done 
> that because the context was simply missing from the mailing lists.

Unfortunately the email medium tends to make what one thinks of as
a neutral and balanced critique appear anything but to the recipient.
And I must say that in this case your messages did have that
appearance.

My only suggestion is for us to all move on to something a little
bit more useful than letting off steam.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Sat, 19 Apr 2008 12:00:35 +0200

[ netfilter-devel and netdev added to CC: ]

> randconfig testing found a netfilter build failure in latest -git:
> 
>   net/netfilter/nf_conntrack_sip.c: In function 'set_expected_rtp_rtcp':
>   net/netfilter/nf_conntrack_sip.c:786: error: 'struct nf_conntrack_expect' has no member named 'saved_ip'
> 
>   http://redhat.com/~mingo/misc/config-Sat_Apr_19_11_37_02_CEST_2008.bad
> 
> disabling CONFIG_NF_CONNTRACK_SIP works it around.

I think this will fix it.

Patrick, is this how we should do it?

diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index c1fc0f1..fd60b2b 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -245,7 +245,7 @@ config NF_CONNTRACK_SANE
 
 config NF_CONNTRACK_SIP
 	tristate "SIP protocol support"
-	depends on NF_CONNTRACK
+	depends on NF_CONNTRACK && NF_NAT
 	default m if NETFILTER_ADVANCED=n
 	help
 	  SIP is an application-layer control protocol that can establish,

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Sat, 19 Apr 2008 12:00:35 +0200
> 
> [ netfilter-devel and netdev added to CC: ]
> 
> > randconfig testing found a netfilter build failure in latest -git:
> > 
> >   net/netfilter/nf_conntrack_sip.c: In function 'set_expected_rtp_rtcp':
> >   net/netfilter/nf_conntrack_sip.c:786: error: 'struct nf_conntrack_expect' has no member named 'saved_ip'
> > 
> >   http://redhat.com/~mingo/misc/config-Sat_Apr_19_11_37_02_CEST_2008.bad
> > 
> > disabling CONFIG_NF_CONNTRACK_SIP works it around.
> 
> I think this will fix it.
> 
> Patrick, is this how we should do it?
> 
> diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
> index c1fc0f1..fd60b2b 100644
> --- a/net/netfilter/Kconfig
> +++ b/net/netfilter/Kconfig
> @@ -245,7 +245,7 @@ config NF_CONNTRACK_SANE
>  
>  config NF_CONNTRACK_SIP
>  	tristate "SIP protocol support"
> -	depends on NF_CONNTRACK
> +	depends on NF_CONNTRACK && NF_NAT
>  	default m if NETFILTER_ADVANCED=n
>  	help
>  	  SIP is an application-layer control protocol that can establish,

thanks David, this solves the build failure here.

Tested-by: Ingo Molnar <mingo@elte.hu>

	Ingo

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Sat, 19 Apr 2008 12:41:52 +0200

> thanks David, this solves the build failure here.
> 
> Tested-by: Ingo Molnar <mingo@elte.hu>

Thanks for testing.

I guess if you had been able to reply to the merge request
thread, this would have been fixed faster, sorry about that.

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Jan Engelhardt]

On Saturday 2008-04-19 12:07, David Miller wrote:
>> randconfig testing found a netfilter build failure in latest -git:
>> 
>>   net/netfilter/nf_conntrack_sip.c: In function 'set_expected_rtp_rtcp':
>>   net/netfilter/nf_conntrack_sip.c:786: error: 'struct nf_conntrack_expect' has no member named 'saved_ip'
>> 
>>   http://redhat.com/~mingo/misc/config-Sat_Apr_19_11_37_02_CEST_2008.bad
>> 
>> disabling CONFIG_NF_CONNTRACK_SIP works it around.
>
>I think this will fix it.
>
>Patrick, is this how we should do it?
>
> config NF_CONNTRACK_SIP
> 	tristate "SIP protocol support"
>-	depends on NF_CONNTRACK
>+	depends on NF_CONNTRACK && NF_NAT
> 	default m if NETFILTER_ADVANCED=n

Not really. One may want to run a system without NAT,
but still with connection tracking (for firewalling) -- think IPv6.

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[David Miller]

From: Jan Engelhardt <jengelh@computergmbh.de>
Date: Sat, 19 Apr 2008 12:44:53 +0200 (CEST)

> 
> On Saturday 2008-04-19 12:07, David Miller wrote:
> >Patrick, is this how we should do it?
> >
> > config NF_CONNTRACK_SIP
> > 	tristate "SIP protocol support"
> >-	depends on NF_CONNTRACK
> >+	depends on NF_CONNTRACK && NF_NAT
> > 	default m if NETFILTER_ADVANCED=n
> 
> Not really. One may want to run a system without NAT,
> but still with connection tracking (for firewalling) -- think IPv6.

But SIP needs the NAT layer in order to get at those
expectation structure members.

What is your alternative fix suggestion then?

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

David Miller wrote:
> From: Ingo Molnar <mingo@elte.hu>
> Date: Sat, 19 Apr 2008 12:00:35 +0200
>
> [ netfilter-devel and netdev added to CC: ]
>
>   
>> randconfig testing found a netfilter build failure in latest -git:
>>
>>   net/netfilter/nf_conntrack_sip.c: In function 'set_expected_rtp_rtcp':
>>   net/netfilter/nf_conntrack_sip.c:786: error: 'struct nf_conntrack_expect' has no member named 'saved_ip'
>>
>>   http://redhat.com/~mingo/misc/config-Sat_Apr_19_11_37_02_CEST_2008.bad
>>
>> disabling CONFIG_NF_CONNTRACK_SIP works it around.
>>     
>
> I think this will fix it.
>
> Patrick, is this how we should do it?

No, the SIP helper is also useful without NAT. This patch adds
an ifdef around the RTP call optimization for NATed clients.

Signed-off-by: Patrick McHardy <kaber@trash.net>



[-- Attachment #2: x --]
[-- Type: text/plain, Size: 806 bytes --]

diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index 65b3ba5..9f49000 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -781,7 +781,7 @@ static int set_expected_rtp_rtcp(struct sk_buff *skb,
 		    nfct_help(exp->master)->helper != nfct_help(ct)->helper ||
 		    exp->class != class)
 			break;
-
+#ifdef CONFIG_NF_NAT_NEEDED
 		if (exp->tuple.src.l3num == AF_INET && !direct_rtp &&
 		    (exp->saved_ip != exp->tuple.dst.u3.ip ||
 		     exp->saved_proto.udp.port != exp->tuple.dst.u.udp.port) &&
@@ -791,6 +791,7 @@ static int set_expected_rtp_rtcp(struct sk_buff *skb,
 			tuple.dst.u.udp.port	= exp->saved_proto.udp.port;
 			direct_rtp = 1;
 		} else
+#endif
 			skip_expect = 1;
 	} while (!skip_expect);
 	rcu_read_unlock();

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Sat, 19 Apr 2008 18:38:41 +0200

> David Miller wrote:
> > From: Ingo Molnar <mingo@elte.hu>
> > Date: Sat, 19 Apr 2008 12:00:35 +0200
> >
> > [ netfilter-devel and netdev added to CC: ]
> >
> >   
> >> randconfig testing found a netfilter build failure in latest -git:
> >>
> >>   net/netfilter/nf_conntrack_sip.c: In function 'set_expected_rtp_rtcp':
> >>   net/netfilter/nf_conntrack_sip.c:786: error: 'struct nf_conntrack_expect' has no member named 'saved_ip'
> >>
> >>   http://redhat.com/~mingo/misc/config-Sat_Apr_19_11_37_02_CEST_2008.bad
> >>
> >> disabling CONFIG_NF_CONNTRACK_SIP works it around.
> >>     
> >
> > I think this will fix it.
> >
> > Patrick, is this how we should do it?
> 
> No, the SIP helper is also useful without NAT. This patch adds
> an ifdef around the RTP call optimization for NATed clients.
> 
> Signed-off-by: Patrick McHardy <kaber@trash.net>

Fair enough, applied, thanks Patrick.

Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

[Jeff Garzik]

Ingo Molnar wrote:
> btw., i found no thread to reply to on lkml or elsewhere - arent all git 
> pull requests supposed to be Cc:-ed to lkml, with shortlog included?

That's in the realm of maintainer choice, much like plenty of other 
engineering practices.  There is no "rule" as such.

	Jeff