linux-next: build failure after merge of the v9fs tree

linux-next: build failure after merge of the v9fs tree

[Stephen Rothwell]

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

Hi all,

After merging the v9fs tree, today's linux-next build (i386 defconfig)
failed like this:

In file included from include/linux/kernel.h:29,
                 from arch/x86/include/asm/percpu.h:27,
                 from arch/x86/include/asm/nospec-branch.h:14,
                 from arch/x86/include/asm/paravirt_types.h:27,
                 from arch/x86/include/asm/ptrace.h:97,
                 from arch/x86/include/asm/math_emu.h:5,
                 from arch/x86/include/asm/processor.h:13,
                 from arch/x86/include/asm/timex.h:5,
                 from include/linux/timex.h:67,
                 from include/linux/time32.h:13,
                 from include/linux/time.h:60,
                 from include/linux/stat.h:19,
                 from include/linux/module.h:13,
                 from net/9p/client.c:11:
net/9p/client.c: In function 'p9_check_errors':
include/linux/kern_levels.h:5:25: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
    5 | #define KERN_SOH        "\001"          /* ASCII Start Of Header */
      |                         ^~~~~~
include/linux/printk.h:429:25: note: in definition of macro 'printk_index_wrap'
  429 |                 _p_func(_fmt, ##__VA_ARGS__);                           \
      |                         ^~~~
include/linux/printk.h:500:9: note: in expansion of macro 'printk'
  500 |         printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
      |         ^~~~~~
include/linux/kern_levels.h:11:25: note: in expansion of macro 'KERN_SOH'
   11 | #define KERN_ERR        KERN_SOH "3"    /* error conditions */
      |                         ^~~~~~~~
include/linux/printk.h:500:16: note: in expansion of macro 'KERN_ERR'
  500 |         printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
      |                ^~~~~~~~
net/9p/client.c:523:17: note: in expansion of macro 'pr_err'
  523 |                 pr_err(
      |                 ^~~~~~
cc1: all warnings being treated as errors

Caused by commit

  36cd2f80abf8 ("net/9p: fix response size check in p9_check_errors()")

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 5 Dec 2022 14:55:10 +1100
Subject: [PATCH] net/9p: use %zu to print size_t

Fixes: 36cd2f80abf8 ("net/9p: fix response size check in p9_check_errors()")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/9p/client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/9p/client.c b/net/9p/client.c
index deb7baa178f3..6db5e0c55f9c 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -521,7 +521,7 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
 	err = p9_parse_header(&req->rc, NULL, &type, NULL, 0);
 	if (req->rc.size > req->rc.capacity && !req->rc.zc) {
 		pr_err(
-			 "requested packet size too big: %d does not fit %ld (type=%d)\n",
+			 "requested packet size too big: %d does not fit %zu (type=%d)\n",
 			 req->rc.size, req->rc.capacity, req->rc.id);
 		return -EIO;
 	}
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the v9fs tree

[Dominique Martinet]

Stephen Rothwell wrote on Mon, Dec 05, 2022 at 03:03:16PM +1100:
> After merging the v9fs tree, today's linux-next build (i386 defconfig)
> failed like this:
> 
> In file included from include/linux/kernel.h:29,
>                  from arch/x86/include/asm/percpu.h:27,
>                  from arch/x86/include/asm/nospec-branch.h:14,
>                  from arch/x86/include/asm/paravirt_types.h:27,
>                  from arch/x86/include/asm/ptrace.h:97,
>                  from arch/x86/include/asm/math_emu.h:5,
>                  from arch/x86/include/asm/processor.h:13,
>                  from arch/x86/include/asm/timex.h:5,
>                  from include/linux/timex.h:67,
>                  from include/linux/time32.h:13,
>                  from include/linux/time.h:60,
>                  from include/linux/stat.h:19,
>                  from include/linux/module.h:13,
>                  from net/9p/client.c:11:
> net/9p/client.c: In function 'p9_check_errors':
> include/linux/kern_levels.h:5:25: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
>     5 | #define KERN_SOH        "\001"          /* ASCII Start Of Header */
>       |                         ^~~~~~
> include/linux/printk.h:429:25: note: in definition of macro 'printk_index_wrap'
>   429 |                 _p_func(_fmt, ##__VA_ARGS__);                           \
>       |                         ^~~~
> include/linux/printk.h:500:9: note: in expansion of macro 'printk'
>   500 |         printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>       |         ^~~~~~
> include/linux/kern_levels.h:11:25: note: in expansion of macro 'KERN_SOH'
>    11 | #define KERN_ERR        KERN_SOH "3"    /* error conditions */
>       |                         ^~~~~~~~
> include/linux/printk.h:500:16: note: in expansion of macro 'KERN_ERR'
>   500 |         printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>       |                ^~~~~~~~
> net/9p/client.c:523:17: note: in expansion of macro 'pr_err'
>   523 |                 pr_err(
>       |                 ^~~~~~
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   36cd2f80abf8 ("net/9p: fix response size check in p9_check_errors()")
> 
> I have applied the following patch for today:

Thank you!
I guess I should start building one 32bit kernel somewhere...

I've amended the bad commit with this and added a note to the patch
thanking you (not quite sure how to express that with xx-by: like tags,
it's just words -- if you care and have a suggestion feel free)

-- 
Dominique

Re: linux-next: build failure after merge of the v9fs tree

[Stephen Rothwell]

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

Hi Dominique,

On Mon, 5 Dec 2022 13:10:18 +0900 Dominique Martinet <asmadeus@codewreck.org> wrote:
>
> I've amended the bad commit with this and added a note to the patch
> thanking you (not quite sure how to express that with xx-by: like tags,
> it's just words -- if you care and have a suggestion feel free)

Looks good to me.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the v9fs tree

[Christian Schoenebeck]

On Monday, December 5, 2022 5:10:18 AM CET Dominique Martinet wrote:
> Stephen Rothwell wrote on Mon, Dec 05, 2022 at 03:03:16PM +1100:
> > After merging the v9fs tree, today's linux-next build (i386 defconfig)
> > failed like this:
[...]
> > net/9p/client.c:523:17: note: in expansion of macro 'pr_err'
> >   523 |                 pr_err(
> >       |                 ^~~~~~
> > cc1: all warnings being treated as errors
> > 
> > Caused by commit
> > 
> >   36cd2f80abf8 ("net/9p: fix response size check in p9_check_errors()")
> > 
> > I have applied the following patch for today:
> 
> Thank you!
> I guess I should start building one 32bit kernel somewhere...

:/ I'll setup a 32-bit build system as well, sorry!

Best regards,
Christian Schoenebeck

Re: linux-next: build failure after merge of the v9fs tree

[Christian Schoenebeck]

On Monday, December 5, 2022 3:31:57 PM CET Christian Schoenebeck wrote:
> On Monday, December 5, 2022 5:10:18 AM CET Dominique Martinet wrote:
> > Stephen Rothwell wrote on Mon, Dec 05, 2022 at 03:03:16PM +1100:
> > > After merging the v9fs tree, today's linux-next build (i386 defconfig)
> 
> > > failed like this:
> [...]
> 
> > > net/9p/client.c:523:17: note: in expansion of macro 'pr_err'
> > > 
> > >   523 |                 pr_err(
> > >   
> > >       |                 ^~~~~~
> > > 
> > > cc1: all warnings being treated as errors
> > > 
> > > Caused by commit
> > > 
> > >   36cd2f80abf8 ("net/9p: fix response size check in p9_check_errors()")
> > > 
> > > I have applied the following patch for today:
> > Thank you!
> > I guess I should start building one 32bit kernel somewhere...
> :
> :/ I'll setup a 32-bit build system as well, sorry!

Dominique, looking at your 9p queue, I just realized what happened here: I 
posted a v2 of these two patches, which got lost for some reason:

https://lore.kernel.org/all/cover.1669144861.git.linux_oss@crudebyte.com/

The currently queued 1st patch is still v1 as well.

Best regards,
Christian Schoenebeck

Re: linux-next: build failure after merge of the v9fs tree

[Dominique Martinet]

Christian Schoenebeck wrote on Mon, Dec 05, 2022 at 09:40:06PM +0100:
> Dominique, looking at your 9p queue, I just realized what happened here: I 
> posted a v2 of these two patches, which got lost for some reason:
> 
> https://lore.kernel.org/all/cover.1669144861.git.linux_oss@crudebyte.com/
> 
> The currently queued 1st patch is still v1 as well.

Oh. Now how did I manage that one..
Thanks for the catch, and v2 had the valid printf modifier...

Sorry for all the trouble :(
-- 
Dominique

Re: linux-next: build failure after merge of the v9fs tree

[Christian Schoenebeck]

On Monday, December 5, 2022 11:41:55 PM CET Dominique Martinet wrote:
> Christian Schoenebeck wrote on Mon, Dec 05, 2022 at 09:40:06PM +0100:
> > Dominique, looking at your 9p queue, I just realized what happened here: I 
> > posted a v2 of these two patches, which got lost for some reason:
> > 
> > https://lore.kernel.org/all/cover.1669144861.git.linux_oss@crudebyte.com/
> > 
> > The currently queued 1st patch is still v1 as well.
> 
> Oh. Now how did I manage that one..
> Thanks for the catch, and v2 had the valid printf modifier...

You remember updating the 1st patch as well, right? :)

In general, I'm sure nobody complains about extra noise like "queued on...".
Then it's also more likely for other people to get which patches are still
pending or unseen.

Re: linux-next: build failure after merge of the v9fs tree

[Dominique Martinet]

Christian Schoenebeck wrote on Thu, Dec 08, 2022 at 04:55:17PM +0100:
> On Monday, December 5, 2022 11:41:55 PM CET Dominique Martinet wrote:
> > Christian Schoenebeck wrote on Mon, Dec 05, 2022 at 09:40:06PM +0100:
> > > Dominique, looking at your 9p queue, I just realized what happened here: I 
> > > posted a v2 of these two patches, which got lost for some reason:
> > > 
> > > https://lore.kernel.org/all/cover.1669144861.git.linux_oss@crudebyte.com/
> > > 
> > > The currently queued 1st patch is still v1 as well.
> > 
> > Oh. Now how did I manage that one..
> > Thanks for the catch, and v2 had the valid printf modifier...
> 
> You remember updating the 1st patch as well, right? :)

It looks up to date to me, e.g. zc is added at the end of the p9_fcall
structure.
(and these are the only two patches you sent, right? :D)

> In general, I'm sure nobody complains about extra noise like "queued on...".
> Then it's also more likely for other people to get which patches are still
> pending or unseen.

I usually apply the patch locally when writing a note about 'taking the
patch for x' -- but the problem is my workflow is pretty manual to say
the least (piping mail to base64, base64 to git am on another
machine...); and I'm not always taking the time to run tests immediately
so not pushing right away to -next, so I assume I took your patches
early and looked back when testing after you sent v2 and they were there
so did't notice :/

I guess I need to pull the tree back and script a reply from the last
link or something; so you'll notice the reply is on v1 in this case?
but it'll be a pain to get the subject back like e.g. pwbot does for
netdev... hmm..
I'll think about what I can do.

-- 
Dominique

Re: linux-next: build failure after merge of the v9fs tree

[Christian Schoenebeck]

On Friday, December 9, 2022 12:53:35 AM CET Dominique Martinet wrote:
> Christian Schoenebeck wrote on Thu, Dec 08, 2022 at 04:55:17PM +0100:
> > On Monday, December 5, 2022 11:41:55 PM CET Dominique Martinet wrote:
> > > Christian Schoenebeck wrote on Mon, Dec 05, 2022 at 09:40:06PM +0100:
> > > > Dominique, looking at your 9p queue, I just realized what happened here: I 
> > > > posted a v2 of these two patches, which got lost for some reason:
> > > > 
> > > > https://lore.kernel.org/all/cover.1669144861.git.linux_oss@crudebyte.com/
> > > > 
> > > > The currently queued 1st patch is still v1 as well.
> > > 
> > > Oh. Now how did I manage that one..
> > > Thanks for the catch, and v2 had the valid printf modifier...
> > 
> > You remember updating the 1st patch as well, right? :)
> 
> It looks up to date to me, e.g. zc is added at the end of the p9_fcall
> structure.
> (and these are the only two patches you sent, right? :D)

Mmm, that's the queued patch I see:
https://github.com/martinetd/linux/commit/298468c26c14682a5be80a6ec1b4880c8eb3b261

Which is v1 ('zc' is not at the end of the structure, and in v1 there were
multiple assignment in the same line like:

  req->tc.zc = req->rc.zc = false;

which caused code style checker to bark (as well as on the commit log which it
found too short). So in v2 it is:

  req->tc.zc = false;
  req->rc.zc = false;

And yes, only two patches. :)

> > In general, I'm sure nobody complains about extra noise like "queued on...".
> > Then it's also more likely for other people to get which patches are still
> > pending or unseen.
> 
> I usually apply the patch locally when writing a note about 'taking the
> patch for x' -- but the problem is my workflow is pretty manual to say
> the least (piping mail to base64, base64 to git am on another
> machine...); and I'm not always taking the time to run tests immediately
> so not pushing right away to -next, so I assume I took your patches
> early and looked back when testing after you sent v2 and they were there
> so did't notice :/
> 
> I guess I need to pull the tree back and script a reply from the last
> link or something; so you'll notice the reply is on v1 in this case?
> but it'll be a pain to get the subject back like e.g. pwbot does for
> netdev... hmm..
> I'll think about what I can do.

Well, workflows are quite different. Personally I always manually reply to
mailed patches once I queued them, so that people can verify and correct me in
case I queued the wrong ones. I never had the feeling to script that part.

There are also people that use tools to keep track of all incoming patches,
e.g. patchwork client (either the CLI tool, or the web interface):
https://patchwork.readthedocs.io/en/latest/usage/clients/

The advantage is that it can take care about submitted versions and you just
mark queued series as done. If you don't have an account it is read-only, so
you can view pending patches, their status, automatically apply them, but for
changing their official status somebody has to create an account for you:
https://lore.kernel.org/all/2915273.dLz0rCdnKo@silver/

There are various patchwork hosts. Not sure who is responsible for creating
patchwork accounts on lore.kernel.org.

The Redhat guys are using Patchew, e.g.:
https://patchew.org/QEMU/

Re: linux-next: build failure after merge of the v9fs tree

[Dominique Martinet]

Christian Schoenebeck wrote on Fri, Dec 09, 2022 at 03:40:06PM +0100:
> > > You remember updating the 1st patch as well, right? :)
> > 
> > It looks up to date to me, e.g. zc is added at the end of the p9_fcall
> > structure.
> > (and these are the only two patches you sent, right? :D)
> 
> Mmm, that's the queued patch I see:
> https://github.com/martinetd/linux/commit/298468c26c14682a5be80a6ec1b4880c8eb3b261
> 
> Which is v1 ('zc' is not at the end of the structure, and in v1 there were
> multiple assignment in the same line like:
> 
>   req->tc.zc = req->rc.zc = false;
> 
> which caused code style checker to bark (as well as on the commit log which it
> found too short). So in v2 it is:
> 
>   req->tc.zc = false;
>   req->rc.zc = false;
> 
> And yes, only two patches. :)

Ah. . . what did I just say about applying patches in my local branch
for testing later, they correct one is just sitting there but wasn't
tested/pushed yet :/

(if you care, I'm using my 9p-test branch for that, but it's not sent
sent to -next obviously)


> Well, workflows are quite different. Personally I always manually reply to
> mailed patches once I queued them, so that people can verify and correct me in
> case I queued the wrong ones. I never had the feeling to script that part.

Yes I usually do write a note about it when I take the patch locally,
but in this case I think I just applied the patches for checkpatch
(indentation looked off without being sure it'd complain) and didn't
intend to queue it; then came back later and "oh they're here, thanks
past me!" (incorrectly)

I guess at this point the problem comes back down to not running
tests/pushing to next immediately; if I finish automating that part I
think this kind of errors wouldn't happen as non-pushed patches wouldn't
make sense...
Well, it's been rare enough but still worth thinking about safeguards
imo, there's usually a reason for v2 patchs so getting the v1 in even
occasionally is bad :-D

-- 
Dominique

Re: linux-next: build failure after merge of the v9fs tree

[Dominique Martinet]

Stephen Rothwell wrote on Wed, Jul 13, 2022 at 11:02:22AM +1000:
> After merging the v9fs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> net/9p/trans_fd.c:275:12: error: 'failme' defined but not used [-Werror=unused-variable]
>   275 | static int failme;
>       |            ^~~~~~
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   c249fb4f9193 ("9p: roll p9_tag_remove into p9_req_put")
> 
> I have used the v9fs tree from next-20220712 for today.

Sorry, fixed in my tree.

That can wait tomorrow.

--
Dominique

linux-next: build failure after merge of the v9fs tree

[Stephen Rothwell]

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

Hi all,

After merging the v9fs tree, today's linux-next build (x86_64
allmodconfig) failed like this:

net/9p/trans_fd.c:275:12: error: 'failme' defined but not used [-Werror=unused-variable]
  275 | static int failme;
      |            ^~~~~~
cc1: all warnings being treated as errors

Caused by commit

  c249fb4f9193 ("9p: roll p9_tag_remove into p9_req_put")

I have used the v9fs tree from next-20220712 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the v9fs tree

[Joe Perches]

On Thu, 2011-12-01 at 12:02 +1100, Stephen Rothwell wrote:
> Hi Eric,
> 
> After merging the v9fs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "_p9_debug" [net/9p/9pnet_virtio.ko] undefined!
> ERROR: "_p9_debug" [net/9p/9pnet_rdma.ko] undefined!
> ERROR: "_p9_debug" [net/9p/9pnet.ko] undefined!
> 
> Caused by commit be9e4aa9e783 ("9p: Reduce object size with
> CONFIG_NET_9P_DEBUG").
> 
> I have used the v9fs tree from next-20111130 for today.

Thanks Stephen.

Clearly I didn't sufficiently compile test this.
Sorry.  I'll resubmit.

linux-next: build failure after merge of the v9fs tree

[Stephen Rothwell]

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

Hi Eric,

After merging the v9fs tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "_p9_debug" [net/9p/9pnet_virtio.ko] undefined!
ERROR: "_p9_debug" [net/9p/9pnet_rdma.ko] undefined!
ERROR: "_p9_debug" [net/9p/9pnet.ko] undefined!

Caused by commit be9e4aa9e783 ("9p: Reduce object size with
CONFIG_NET_9P_DEBUG").

I have used the v9fs tree from next-20111130 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the v9fs tree

[Venkateswararao Jujjuri (JV)]

On 2/22/2011 6:57 AM, Eric Van Hensbergen wrote:
> JV - you should be able to check this just by building with allmod
> config.  I'll accept a pull immediately if this is the fix.

Yeah; it works fine with this patch.

Thanks,
JV

> 
>         -eric
> 
> 
> On Tue, Feb 22, 2011 at 12:22 AM, Venkateswararao Jujjuri (JV)
> <jvrao@linux.vnet.ibm.com> wrote:
>> On 2/21/2011 9:30 PM, Stephen Rothwell wrote:
>>> Hi,
>>>
>>> On Mon, 21 Feb 2011 21:20:31 -0800 "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com> wrote:
>>>>
>>>> On 2/21/2011 4:53 PM, Stephen Rothwell wrote:
>>>>>
>>>>> After merging the v9fs tree, today's linux-next build (x86_64
>>>>> allmodconfig) failed like this:
>>>>>
>>>>> ERROR: "p9_payload_gup" [net/9p/9pnet_virtio.ko] undefined!
>>>>> ERROR: "p9_nr_pages" [net/9p/9pnet_virtio.ko] undefined!
>>>>> ERROR: "p9_release_req_pages" [net/9p/9pnet_virtio.ko] undefined!
>>>>
>>>> These functions are defined by commit 249951bf66816128a7698caa826425e299494c82
>>>> ([net/9p] Preparation and helper functions for zero copy)
>>>
>>> Yes, they are - but they are not exported to modules.
>>
>> Thanks; Can you please check if this patch fixes your issue?
>>
>> diff --git a/net/9p/trans_common.c b/net/9p/trans_common.c
>> index ca705f1..da7c2cd 100644
>> --- a/net/9p/trans_common.c
>> +++ b/net/9p/trans_common.c
>> @@ -13,6 +13,7 @@
>>  */
>>
>>  #include <linux/slab.h>
>> + #include <linux/module.h>
>>  #include <net/9p/9p.h>
>>  #include <net/9p/client.h>
>>  #include <linux/scatterlist.h>
>> @@ -32,6 +33,7 @@ p9_release_req_pages(struct trans_rpage_info *rpinfo)
>>                i++;
>>        }
>>  }
>> +EXPORT_SYMBOL(p9_release_req_pages);
>>
>>  /**
>>  * p9_nr_pages - Return number of pages needed to accomodate the payload.
>> @@ -45,6 +47,7 @@ p9_nr_pages(struct p9_req_t *req)
>>                        PAGE_SIZE - 1) >> PAGE_SHIFT;
>>        return end_page - start_page;
>>  }
>> +EXPORT_SYMBOL(p9_nr_pages);
>>
>>  /**
>>  * payload_gup - Translates user buffer into kernel pages and
>> @@ -91,3 +94,4 @@ p9_payload_gup(struct p9_req_t *req, size_t *pdata_off, int *p
>>        }
>>        return 0;
>>  }
>> +EXPORT_SYMBOL(p9_payload_gup);
>>
>>
>>
>>

Re: linux-next: build failure after merge of the v9fs tree

[Eric Van Hensbergen]

JV - you should be able to check this just by building with allmod
config.  I'll accept a pull immediately if this is the fix.

        -eric


On Tue, Feb 22, 2011 at 12:22 AM, Venkateswararao Jujjuri (JV)
<jvrao@linux.vnet.ibm.com> wrote:
> On 2/21/2011 9:30 PM, Stephen Rothwell wrote:
>> Hi,
>>
>> On Mon, 21 Feb 2011 21:20:31 -0800 "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com> wrote:
>>>
>>> On 2/21/2011 4:53 PM, Stephen Rothwell wrote:
>>>>
>>>> After merging the v9fs tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> ERROR: "p9_payload_gup" [net/9p/9pnet_virtio.ko] undefined!
>>>> ERROR: "p9_nr_pages" [net/9p/9pnet_virtio.ko] undefined!
>>>> ERROR: "p9_release_req_pages" [net/9p/9pnet_virtio.ko] undefined!
>>>
>>> These functions are defined by commit 249951bf66816128a7698caa826425e299494c82
>>> ([net/9p] Preparation and helper functions for zero copy)
>>
>> Yes, they are - but they are not exported to modules.
>
> Thanks; Can you please check if this patch fixes your issue?
>
> diff --git a/net/9p/trans_common.c b/net/9p/trans_common.c
> index ca705f1..da7c2cd 100644
> --- a/net/9p/trans_common.c
> +++ b/net/9p/trans_common.c
> @@ -13,6 +13,7 @@
>  */
>
>  #include <linux/slab.h>
> + #include <linux/module.h>
>  #include <net/9p/9p.h>
>  #include <net/9p/client.h>
>  #include <linux/scatterlist.h>
> @@ -32,6 +33,7 @@ p9_release_req_pages(struct trans_rpage_info *rpinfo)
>                i++;
>        }
>  }
> +EXPORT_SYMBOL(p9_release_req_pages);
>
>  /**
>  * p9_nr_pages - Return number of pages needed to accomodate the payload.
> @@ -45,6 +47,7 @@ p9_nr_pages(struct p9_req_t *req)
>                        PAGE_SIZE - 1) >> PAGE_SHIFT;
>        return end_page - start_page;
>  }
> +EXPORT_SYMBOL(p9_nr_pages);
>
>  /**
>  * payload_gup - Translates user buffer into kernel pages and
> @@ -91,3 +94,4 @@ p9_payload_gup(struct p9_req_t *req, size_t *pdata_off, int *p
>        }
>        return 0;
>  }
> +EXPORT_SYMBOL(p9_payload_gup);
>
>
>
>

Re: linux-next: build failure after merge of the v9fs tree

[Venkateswararao Jujjuri (JV)]

On 2/21/2011 9:30 PM, Stephen Rothwell wrote:
> Hi,
> 
> On Mon, 21 Feb 2011 21:20:31 -0800 "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com> wrote:
>>
>> On 2/21/2011 4:53 PM, Stephen Rothwell wrote:
>>>
>>> After merging the v9fs tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> ERROR: "p9_payload_gup" [net/9p/9pnet_virtio.ko] undefined!
>>> ERROR: "p9_nr_pages" [net/9p/9pnet_virtio.ko] undefined!
>>> ERROR: "p9_release_req_pages" [net/9p/9pnet_virtio.ko] undefined!
>>
>> These functions are defined by commit 249951bf66816128a7698caa826425e299494c82
>> ([net/9p] Preparation and helper functions for zero copy)
> 
> Yes, they are - but they are not exported to modules.

Thanks; Can you please check if this patch fixes your issue?

diff --git a/net/9p/trans_common.c b/net/9p/trans_common.c
index ca705f1..da7c2cd 100644
--- a/net/9p/trans_common.c
+++ b/net/9p/trans_common.c
@@ -13,6 +13,7 @@
  */

 #include <linux/slab.h>
+ #include <linux/module.h>
 #include <net/9p/9p.h>
 #include <net/9p/client.h>
 #include <linux/scatterlist.h>
@@ -32,6 +33,7 @@ p9_release_req_pages(struct trans_rpage_info *rpinfo)
                i++;
        }
 }
+EXPORT_SYMBOL(p9_release_req_pages);

 /**
  * p9_nr_pages - Return number of pages needed to accomodate the payload.
@@ -45,6 +47,7 @@ p9_nr_pages(struct p9_req_t *req)
                        PAGE_SIZE - 1) >> PAGE_SHIFT;
        return end_page - start_page;
 }
+EXPORT_SYMBOL(p9_nr_pages);

 /**
  * payload_gup - Translates user buffer into kernel pages and
@@ -91,3 +94,4 @@ p9_payload_gup(struct p9_req_t *req, size_t *pdata_off, int *p
        }
        return 0;
 }
+EXPORT_SYMBOL(p9_payload_gup);

Re: linux-next: build failure after merge of the v9fs tree

[Stephen Rothwell]

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

Hi,

On Mon, 21 Feb 2011 21:20:31 -0800 "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com> wrote:
>
> On 2/21/2011 4:53 PM, Stephen Rothwell wrote:
> > 
> > After merging the v9fs tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > ERROR: "p9_payload_gup" [net/9p/9pnet_virtio.ko] undefined!
> > ERROR: "p9_nr_pages" [net/9p/9pnet_virtio.ko] undefined!
> > ERROR: "p9_release_req_pages" [net/9p/9pnet_virtio.ko] undefined!
> 
> These functions are defined by commit 249951bf66816128a7698caa826425e299494c82
> ([net/9p] Preparation and helper functions for zero copy)

Yes, they are - but they are not exported to modules.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: build failure after merge of the v9fs tree

[Venkateswararao Jujjuri (JV)]

On 2/21/2011 4:53 PM, Stephen Rothwell wrote:
> Hi Eric,
> 
> After merging the v9fs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "p9_payload_gup" [net/9p/9pnet_virtio.ko] undefined!
> ERROR: "p9_nr_pages" [net/9p/9pnet_virtio.ko] undefined!
> ERROR: "p9_release_req_pages" [net/9p/9pnet_virtio.ko] undefined!

These functions are defined by commit 249951bf66816128a7698caa826425e299494c82
([net/9p] Preparation and helper functions for zero copy)

Thanks,
JV

> 
> Caused by commit ac8c81621fe5176f1bb18730e5db2e347af08255 ("[net/9p] Add
> gup/zero_copy support to VirtIO transport layer").
> 
> I have used the v9fs tree from next-20110221 for today.

linux-next: build failure after merge of the v9fs tree

[Stephen Rothwell]

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

Hi Eric,

After merging the v9fs tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "p9_payload_gup" [net/9p/9pnet_virtio.ko] undefined!
ERROR: "p9_nr_pages" [net/9p/9pnet_virtio.ko] undefined!
ERROR: "p9_release_req_pages" [net/9p/9pnet_virtio.ko] undefined!

Caused by commit ac8c81621fe5176f1bb18730e5db2e347af08255 ("[net/9p] Add
gup/zero_copy support to VirtIO transport layer").

I have used the v9fs tree from next-20110221 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]