From: Chuck Lever <chuck.lever@oracle.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, linux-next@vger.kernel.org
Subject: Re: linux-next: nfs build failure
Date: Wed, 18 Jun 2008 16:37:06 -0400 [thread overview]
Message-ID: <485971F2.8000005@oracle.com> (raw)
In-Reply-To: <1213820042.8233.21.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]
Trond Myklebust wrote:
> On Wed, 2008-06-18 at 12:52 +1000, Stephen Rothwell wrote:
>> Hi Trond,
>>
>> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>>
>> fs/built-in.o: In function `.nfs_parse_ip_address':
>> super.c:(.text+0xe2f08): undefined reference to `.__ipv6_addr_type'
>>
>> Some CONFIG_IPV6 protections are needed ...
>>
>> I reverted commit 09491a874d4f9a8676567bc58bce9dec9539740d ("NFS: handle
>> interface identifiers in incoming IPv6 addresses").
>
> I suggest something like the attached patch. Comments Chuck?
>
> Trond
>
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> NFS: Don't allow IPv6 addresses if CONFIG_IPv6 isn't set
> From:
> Trond Myklebust <Trond.Myklebust@netapp.com>
> Date:
> Wed, 18 Jun 2008 16:04:22 -0400
>
>
> Fixes a compile failure in fs/nfs/super.c
>
> Also fix the compiler warnings:
> fs/nfs/super.c:721: warning: field width should have type ‘int’, but
> argument 2 has type ‘size_t’
I just saw this warning yesterday, and was about to send a fix for it.
Sorry for the delay, but I had a power supply go south on me today.
> fs/nfs/super.c:809:3: warning: returning void-valued expression
> fs/nfs/super.c:811:3: warning: returning void-valued expression
But I've never seen that one. Very strange how the warnings vary
depending on what platform you compile to.
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> ---
>
> fs/nfs/super.c | 19 ++++++++++++++-----
> 1 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index e62820c..6a47bc3 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -718,10 +718,10 @@ static void nfs_parse_ipv4_address(char *string, size_t str_len,
> struct sockaddr_in *sin = (struct sockaddr_in *)sap;
> u8 *addr = (u8 *)&sin->sin_addr.s_addr;
>
> - dfprintk(MOUNT, "NFS: parsing IPv4 address %*s\n",
> - str_len, string);
> -
> if (str_len <= INET_ADDRSTRLEN) {
> + dfprintk(MOUNT, "NFS: parsing IPv4 address %*s\n",
> + (int)str_len, string);
> +
You need the same fix in nfs_parse_ipv6_address().
> sin->sin_family = AF_INET;
> *addr_len = sizeof(*sin);
> if (in4_pton(string, str_len, addr, '\0', NULL))
> @@ -732,6 +732,7 @@ static void nfs_parse_ipv4_address(char *string, size_t str_len,
> *addr_len = 0;
> }
>
> +#ifdef CONFIG_IPV6
> static void nfs_parse_ipv6_scope_id(const char *string, const size_t str_len,
> const char *delim,
> struct sockaddr_in6 *sin6)
> @@ -787,6 +788,14 @@ static void nfs_parse_ipv6_address(char *string, size_t str_len,
> sap->sa_family = AF_UNSPEC;
> *addr_len = 0;
> }
> +#else
> +static void nfs_parse_ipv6_address(char *string, size_t str_len,
> + struct sockaddr *sap, size_t *addr_len)
> +{
> + sap->sa_family = AF_UNSPEC;
> + *addr_len = 0;
> +}
> +#endif
Instead of creating a separate function, you could just wrap everything
in nfs_parse_ipv6_address() but these two lines with #ifdef CONFIG_IPV6
/ #endif.
>
> /*
> * Construct a sockaddr based on the contents of a string that contains
> @@ -806,9 +815,9 @@ static void nfs_parse_ip_address(char *string, size_t str_len,
> colons++;
>
> if (colons >= 2)
> - return nfs_parse_ipv6_address(string, str_len, sap, addr_len);
> + nfs_parse_ipv6_address(string, str_len, sap, addr_len);
> else
> - return nfs_parse_ipv4_address(string, str_len, sap, addr_len);
> + nfs_parse_ipv4_address(string, str_len, sap, addr_len);
> }
>
> /*
/me slaps forehead. D'oh!
[-- Attachment #2: chuck_lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard
next prev parent reply other threads:[~2008-06-18 20:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-18 2:52 linux-next: nfs build failure Stephen Rothwell
2008-06-18 20:14 ` Trond Myklebust
2008-06-18 20:37 ` Chuck Lever [this message]
2008-06-18 21:15 ` Trond Myklebust
2008-06-18 21:19 ` Randy Dunlap
2008-06-18 22:18 ` Trond Myklebust
-- strict thread matches above, loose matches on Subject: below --
2008-06-17 9:26 Stephen Rothwell
2008-06-17 20:19 ` Trond Myklebust
2008-06-17 20:37 ` Jeff Layton
2008-06-18 0:49 ` Stephen Rothwell
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=485971F2.8000005@oracle.com \
--to=chuck.lever@oracle.com \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=trond.myklebust@fys.uio.no \
/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.