* [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
@ 2018-06-01 0:36 kbuild test robot
2018-06-01 0:54 ` Al Viro
0 siblings, 1 reply; 11+ messages in thread
From: kbuild test robot @ 2018-06-01 0:36 UTC (permalink / raw)
To: Adam Manzanares
Cc: kbuild-all, linux-fsdevel, Al Viro, Jeff Moyer, Christoph Hellwig
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 0:36 [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap' kbuild test robot
@ 2018-06-01 0:54 ` Al Viro
2018-06-01 1:02 ` Al Viro
2018-06-01 5:13 ` Christoph Hellwig
0 siblings, 2 replies; 11+ messages in thread
From: Al Viro @ 2018-06-01 0:54 UTC (permalink / raw)
To: kbuild test robot
Cc: Adam Manzanares, kbuild-all, linux-fsdevel, Jeff Moyer,
Christoph Hellwig
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...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 0:54 ` Al Viro
@ 2018-06-01 1:02 ` Al Viro
2018-06-01 1:12 ` [kbuild-all] " Li, Philip
2018-06-01 5:13 ` Christoph Hellwig
1 sibling, 1 reply; 11+ messages in thread
From: Al Viro @ 2018-06-01 1:02 UTC (permalink / raw)
To: kbuild test robot
Cc: Adam Manzanares, kbuild-all, linux-fsdevel, Jeff Moyer,
Christoph Hellwig
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...
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [kbuild-all] [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 1:02 ` Al Viro
@ 2018-06-01 1:12 ` Li, Philip
0 siblings, 0 replies; 11+ messages in thread
From: Li, Philip @ 2018-06-01 1:12 UTC (permalink / raw)
To: Al Viro, lkp
Cc: linux-fsdevel, Adam Manzanares, Jeff Moyer, kbuild-all,
Christoph Hellwig
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 0:54 ` Al Viro
2018-06-01 1:02 ` Al Viro
@ 2018-06-01 5:13 ` Christoph Hellwig
2018-06-01 15:38 ` Adam Manzanares
1 sibling, 1 reply; 11+ messages in thread
From: Christoph Hellwig @ 2018-06-01 5:13 UTC (permalink / raw)
To: Al Viro
Cc: kbuild test robot, Adam Manzanares, kbuild-all, linux-fsdevel,
Jeff Moyer, 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 5:13 ` Christoph Hellwig
@ 2018-06-01 15:38 ` Adam Manzanares
2018-06-01 15:41 ` Jens Axboe
0 siblings, 1 reply; 11+ messages in thread
From: Adam Manzanares @ 2018-06-01 15:38 UTC (permalink / raw)
To: Christoph Hellwig, Al Viro, Jens Axboe
Cc: kbuild test robot, kbuild-all, linux-fsdevel, Jeff Moyer
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.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 15:38 ` Adam Manzanares
@ 2018-06-01 15:41 ` Jens Axboe
2018-06-01 15:57 ` Adam Manzanares
0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2018-06-01 15:41 UTC (permalink / raw)
To: Adam Manzanares, Christoph Hellwig, Al Viro
Cc: kbuild test robot, kbuild-all, linux-fsdevel, Jeff Moyer
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 15:41 ` Jens Axboe
@ 2018-06-01 15:57 ` Adam Manzanares
2018-06-01 15:59 ` Jens Axboe
0 siblings, 1 reply; 11+ messages in thread
From: Adam Manzanares @ 2018-06-01 15:57 UTC (permalink / raw)
To: Jens Axboe, Christoph Hellwig, Al Viro
Cc: kbuild test robot, kbuild-all, linux-fsdevel, Jeff Moyer
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 15:57 ` Adam Manzanares
@ 2018-06-01 15:59 ` Jens Axboe
2018-06-01 17:28 ` Matthew Wilcox
0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2018-06-01 15:59 UTC (permalink / raw)
To: Adam Manzanares, Christoph Hellwig, Al Viro
Cc: kbuild test robot, kbuild-all, linux-fsdevel, Jeff Moyer
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 15:59 ` Jens Axboe
@ 2018-06-01 17:28 ` Matthew Wilcox
2018-06-01 20:31 ` Steve French
0 siblings, 1 reply; 11+ messages in thread
From: Matthew Wilcox @ 2018-06-01 17:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Adam Manzanares, Christoph Hellwig, Al Viro, kbuild test robot,
kbuild-all, linux-fsdevel, Jeff Moyer, Steve French, linux-cifs,
linux-nfs
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
2018-06-01 17:28 ` Matthew Wilcox
@ 2018-06-01 20:31 ` Steve French
0 siblings, 0 replies; 11+ messages in thread
From: Steve French @ 2018-06-01 20:31 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jens Axboe, Adam Manzanares, Christoph Hellwig, Al Viro,
kbuild test robot, kbuild-all, linux-fsdevel, Jeff Moyer,
Steve French, CIFS, linux-nfs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-06-01 20:32 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-01 0:36 [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap' kbuild test robot
2018-06-01 0:54 ` Al Viro
2018-06-01 1:02 ` Al Viro
2018-06-01 1:12 ` [kbuild-all] " Li, Philip
2018-06-01 5:13 ` Christoph Hellwig
2018-06-01 15:38 ` Adam Manzanares
2018-06-01 15:41 ` Jens Axboe
2018-06-01 15:57 ` Adam Manzanares
2018-06-01 15:59 ` Jens Axboe
2018-06-01 17:28 ` Matthew Wilcox
2018-06-01 20:31 ` Steve French
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).