* [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).