[vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[kbuild test robot]

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

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.aio
head:   087e566916ce2cde4f20a148607c9c3591f46f67
commit: d9a08a9e616beeccdbd0e7262b7225ffdfa49e92 [10/12] fs: Add aio iopriority support
config: x86_64-randconfig-u0-06010558 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
        git checkout d9a08a9e616beeccdbd0e7262b7225ffdfa49e92
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   fs/aio.o: In function `aio_prep_rw':
>> fs/aio.c:1444: undefined reference to `ioprio_check_cap'

vim +1444 fs/aio.c

  1424	
  1425	static int aio_prep_rw(struct kiocb *req, struct iocb *iocb)
  1426	{
  1427		int ret;
  1428	
  1429		req->ki_filp = fget(iocb->aio_fildes);
  1430		if (unlikely(!req->ki_filp))
  1431			return -EBADF;
  1432		req->ki_complete = aio_complete_rw;
  1433		req->ki_pos = iocb->aio_offset;
  1434		req->ki_flags = iocb_flags(req->ki_filp);
  1435		if (iocb->aio_flags & IOCB_FLAG_RESFD)
  1436			req->ki_flags |= IOCB_EVENTFD;
  1437		req->ki_hint = ki_hint_validate(file_write_hint(req->ki_filp));
  1438		if (iocb->aio_flags & IOCB_FLAG_IOPRIO) {
  1439			/*
  1440			 * If the IOCB_FLAG_IOPRIO flag of aio_flags is set, then
  1441			 * aio_reqprio is interpreted as an I/O scheduling
  1442			 * class and priority.
  1443			 */
> 1444			ret = ioprio_check_cap(iocb->aio_reqprio);
  1445			if (ret) {
  1446				pr_debug("aio ioprio check cap error\n");
  1447				return -EINVAL;
  1448			}
  1449	
  1450			req->ki_ioprio = iocb->aio_reqprio;
  1451		} else
  1452			req->ki_ioprio = IOPRIO_PRIO_VALUE(IOPRIO_CLASS_NONE, 0);
  1453	
  1454		ret = kiocb_set_rw_flags(req, iocb->aio_rw_flags);
  1455		if (unlikely(ret))
  1456			fput(req->ki_filp);
  1457		return ret;
  1458	}
  1459	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29644 bytes --]

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Al Viro]

On Fri, Jun 01, 2018 at 08:36:47AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.aio
> head:   087e566916ce2cde4f20a148607c9c3591f46f67
> commit: d9a08a9e616beeccdbd0e7262b7225ffdfa49e92 [10/12] fs: Add aio iopriority support
> config: x86_64-randconfig-u0-06010558 (attached as .config)
> compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
> reproduce:
>         git checkout d9a08a9e616beeccdbd0e7262b7225ffdfa49e92
>         # save the attached .config to linux build tree
>         make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>    fs/aio.o: In function `aio_prep_rw':
> >> fs/aio.c:1444: undefined reference to `ioprio_check_cap'

Huh?  In the same commit:
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -36,6 +36,7 @@
 #include <linux/delayed_call.h>
 #include <linux/uuid.h>
 #include <linux/errseq.h>
+#include <linux/ioprio.h>

Two commits earlier:
--- a/include/linux/ioprio.h
+++ b/include/linux/ioprio.h
@@ -77,4 +77,6 @@ extern int ioprio_best(unsigned short aprio, unsigned short bprio);
 
 extern int set_task_ioprio(struct task_struct *task, int ioprio);
 
+extern int ioprio_check_cap(int ioprio);
+

and fs/aio.c definitely contains include of linux/fs.h...

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Al Viro]

On Fri, Jun 01, 2018 at 01:54:49AM +0100, Al Viro wrote:
> On Fri, Jun 01, 2018 at 08:36:47AM +0800, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.aio
> > head:   087e566916ce2cde4f20a148607c9c3591f46f67
> > commit: d9a08a9e616beeccdbd0e7262b7225ffdfa49e92 [10/12] fs: Add aio iopriority support
> > config: x86_64-randconfig-u0-06010558 (attached as .config)
> > compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
> > reproduce:
> >         git checkout d9a08a9e616beeccdbd0e7262b7225ffdfa49e92
> >         # save the attached .config to linux build tree
> >         make ARCH=x86_64 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >    fs/aio.o: In function `aio_prep_rw':
> > >> fs/aio.c:1444: undefined reference to `ioprio_check_cap'

gcc-6 ((Debian 6.3.0-18+deb9u1) 6.3.0 20170516) does not trigger that on your
config.  Neither does gcc-5 (Debian 5.4.1-4) 5.4.1 20161202 with the same config
sans GCC_PLUGINS crap...

RE: [kbuild-all] [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Li, Philip]

> On Fri, Jun 01, 2018 at 01:54:49AM +0100, Al Viro wrote:
> > On Fri, Jun 01, 2018 at 08:36:47AM +0800, kbuild test robot wrote:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.aio
> > > head:   087e566916ce2cde4f20a148607c9c3591f46f67
> > > commit: d9a08a9e616beeccdbd0e7262b7225ffdfa49e92 [10/12] fs: Add aio
> iopriority support
> > > config: x86_64-randconfig-u0-06010558 (attached as .config)
> > > compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
> > > reproduce:
> > >         git checkout d9a08a9e616beeccdbd0e7262b7225ffdfa49e92
> > >         # save the attached .config to linux build tree
> > >         make ARCH=x86_64
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > >    fs/aio.o: In function `aio_prep_rw':
> > > >> fs/aio.c:1444: undefined reference to `ioprio_check_cap'
> 
> gcc-6 ((Debian 6.3.0-18+deb9u1) 6.3.0 20170516) does not trigger that on your
> config.  Neither does gcc-5 (Debian 5.4.1-4) 5.4.1 20161202 with the same config
> sans GCC_PLUGINS crap...
thanks for input, we will double check this to check what's possibly wrong.

> _______________________________________________
> kbuild-all mailing list
> kbuild-all@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Christoph Hellwig]

> +extern int ioprio_check_cap(int ioprio);

Which then is implemented in block/ioprio.c, which depends on
CONFIG_BLOCK.  The code either needs a stub for !CONFIG_BLOCK
or moved elsewhere.

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Adam Manzanares]

My vote would be to move the ioprio code into fs/. At first glance I do 
not see a dependence on the block layer in block/ioprio.c.

Any objections?


On 5/31/18 10:13 PM, Christoph Hellwig wrote:
>> +extern int ioprio_check_cap(int ioprio);
> 
> Which then is implemented in block/ioprio.c, which depends on
> CONFIG_BLOCK.  The code either needs a stub for !CONFIG_BLOCK
> or moved elsewhere.
> 

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Jens Axboe]

On 6/1/18 9:38 AM, Adam Manzanares wrote:
> On 5/31/18 10:13 PM, Christoph Hellwig wrote:
>>> +extern int ioprio_check_cap(int ioprio);
>>
>> Which then is implemented in block/ioprio.c, which depends on
>> CONFIG_BLOCK.  The code either needs a stub for !CONFIG_BLOCK
>> or moved elsewhere.
>
> My vote would be to move the ioprio code into fs/. At first glance I do 
> not see a dependence on the block layer in block/ioprio.c.
> 
> Any objections?

Since it's block ioprio code, I'd prefer a stub instead.

-- 
Jens Axboe

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Adam Manzanares]

On 6/1/18 8:41 AM, Jens Axboe wrote:
> On 6/1/18 9:38 AM, Adam Manzanares wrote:
>> On 5/31/18 10:13 PM, Christoph Hellwig wrote:
>>>> +extern int ioprio_check_cap(int ioprio);
>>>
>>> Which then is implemented in block/ioprio.c, which depends on
>>> CONFIG_BLOCK.  The code either needs a stub for !CONFIG_BLOCK
>>> or moved elsewhere.
>>
>> My vote would be to move the ioprio code into fs/. At first glance I do
>> not see a dependence on the block layer in block/ioprio.c.
>>
>> Any objections?
> 
> Since it's block ioprio code, I'd prefer a stub instead.
> 

This feature could be used independently from the block layer. We have 
examples (ATA, hopefully NVME soon) where we are reacting to the ioprio 
in the device drivers essentially passing the ioprio through the block 
layer.

Although I am currently unaware of a concrete example of a device that 
is not using a block layer based driver and has support for IO 
determinism, do you think there is any value in moving all of the block 
ioprio code out of the block layer?

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Jens Axboe]

On 6/1/18 9:57 AM, Adam Manzanares wrote:
> 
> 
> On 6/1/18 8:41 AM, Jens Axboe wrote:
>> On 6/1/18 9:38 AM, Adam Manzanares wrote:
>>> On 5/31/18 10:13 PM, Christoph Hellwig wrote:
>>>>> +extern int ioprio_check_cap(int ioprio);
>>>>
>>>> Which then is implemented in block/ioprio.c, which depends on
>>>> CONFIG_BLOCK.  The code either needs a stub for !CONFIG_BLOCK
>>>> or moved elsewhere.
>>>
>>> My vote would be to move the ioprio code into fs/. At first glance I do
>>> not see a dependence on the block layer in block/ioprio.c.
>>>
>>> Any objections?
>>
>> Since it's block ioprio code, I'd prefer a stub instead.
>>
> 
> This feature could be used independently from the block layer. We have 
> examples (ATA, hopefully NVME soon) where we are reacting to the ioprio 
> in the device drivers essentially passing the ioprio through the block 
> layer.

It could, yes, but it isn't. As it stands, it's system call support to
pass in IO priority for what ultimately is block storage.

> Although I am currently unaware of a concrete example of a device that 
> is not using a block layer based driver and has support for IO 
> determinism, do you think there is any value in moving all of the block 
> ioprio code out of the block layer?

I don't think so.

-- 
Jens Axboe

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Matthew Wilcox]

On Fri, Jun 01, 2018 at 09:59:03AM -0600, Jens Axboe wrote:
> On 6/1/18 9:57 AM, Adam Manzanares wrote:
> > 
> > 
> > On 6/1/18 8:41 AM, Jens Axboe wrote:
> >> On 6/1/18 9:38 AM, Adam Manzanares wrote:
> >>> On 5/31/18 10:13 PM, Christoph Hellwig wrote:
> >>>>> +extern int ioprio_check_cap(int ioprio);
> >>>>
> >>>> Which then is implemented in block/ioprio.c, which depends on
> >>>> CONFIG_BLOCK.  The code either needs a stub for !CONFIG_BLOCK
> >>>> or moved elsewhere.
> >>>
> >>> My vote would be to move the ioprio code into fs/. At first glance I do
> >>> not see a dependence on the block layer in block/ioprio.c.
> >>>
> >>> Any objections?
> >>
> >> Since it's block ioprio code, I'd prefer a stub instead.
> >>
> > 
> > This feature could be used independently from the block layer. We have 
> > examples (ATA, hopefully NVME soon) where we are reacting to the ioprio 
> > in the device drivers essentially passing the ioprio through the block 
> > layer.
> 
> It could, yes, but it isn't. As it stands, it's system call support to
> pass in IO priority for what ultimately is block storage.

I think it'd be interesting if NFS/SMB decided to start using it.
I think SMB has the concept of io priorities within a single stream ...
Steve?

Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'

[Steve French]

On Fri, Jun 1, 2018 at 12:28 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Jun 01, 2018 at 09:59:03AM -0600, Jens Axboe wrote:
>> On 6/1/18 9:57 AM, Adam Manzanares wrote:
>> >
>> >
>> > On 6/1/18 8:41 AM, Jens Axboe wrote:
>> >> On 6/1/18 9:38 AM, Adam Manzanares wrote:
>> >>> On 5/31/18 10:13 PM, Christoph Hellwig wrote:
>> >>>>> +extern int ioprio_check_cap(int ioprio);
>> >>>>
>> >>>> Which then is implemented in block/ioprio.c, which depends on
>> >>>> CONFIG_BLOCK.  The code either needs a stub for !CONFIG_BLOCK
>> >>>> or moved elsewhere.
>> >>>
>> >>> My vote would be to move the ioprio code into fs/. At first glance I do
>> >>> not see a dependence on the block layer in block/ioprio.c.
>> >>>
>> >>> Any objections?
>> >>
>> >> Since it's block ioprio code, I'd prefer a stub instead.
>> >>
>> >
>> > This feature could be used independently from the block layer. We have
>> > examples (ATA, hopefully NVME soon) where we are reacting to the ioprio
>> > in the device drivers essentially passing the ioprio through the block
>> > layer.
>>
>> It could, yes, but it isn't. As it stands, it's system call support to
>> pass in IO priority for what ultimately is block storage.
>
> I think it'd be interesting if NFS/SMB decided to start using it.
> I think SMB has the concept of io priorities within a single stream ...
> Steve?

Yes - in theory SMB3 does, but I need to research this more to
see if useable here.  Will also discuss with others at SambaXP to see
if ideas from others.  Also note that SMB3 has a per-io flag (for read
and write) that allows "unbuffered" and "writethrough" to be set on
a per operation basis (not just on a per-file handle basis).  Would
be interesting if we could get hints on when to set these flags
on a per-operation basis (rather than just on the handle at
open time).

-- 
Thanks,

Steve