RE: [RFC PATCH] io_uring: add support for IORING_OP_GETDENTS64
> One open question is whether IORING_OP_GETDENTS64 should be more like > pread(2) and allow passing in a starting offset to read from the > directory from. (This would require some more surgery in fs/readdir.c.) Since directories are seekable this ought to work. Modulo horrid issues with 32bit file offsets. You'd need to return the final offset to allow another read to continue from the end position. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [RFC PATCH] io_uring: add support for IORING_OP_GETDENTS64
From: Lennert Buytenhek > Sent: 28 January 2021 23:07 > > On Sun, Jan 24, 2021 at 10:21:38PM +0000, David Laight wrote: > > > > One open question is whether IORING_OP_GETDENTS64 should be more like > > > pread(2) and allow passing in a starting offset to read from the > > > directory from. (This would require some more surgery in fs/readdir.c.) > > > > Since directories are seekable this ought to work. > > Modulo horrid issues with 32bit file offsets. > > The incremental patch below does this. (It doesn't apply cleanly on > top of v1 of the IORING_OP_GETDENTS patch as I have other changes in > my tree -- I'm including it just to illustrate the changes that would > make this work.) > > This change seems to work, and makes IORING_OP_GETDENTS take an > explicitly specified directory offset (instead of using the file's > ->f_pos), making it more like pread(2), and I like the change from > a conceptual point of view, but it's a bit ugly around > iterate_dir_use_ctx_pos(). Any thoughts on how to do this more > cleanly (without breaking iterate_dir() semantics)? I had a further thought... I presume the basic operation is: lock(file); do_getents(); // Updates file->offset unlock(file); Which means you can implement an offset by saving, updating and restoring file->offset while the lock is held. This is a bit like the completely broken pread() in uclibc which uses two lseek() calls to set and restore the offset. Whoever wrote that needs shooting - worse than useless. Glibc is as bad: // Don't even ask what glibc's clock_nanosleep() does, you don't want to know. while (syscall(SYS_clock_nanosleep, CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, NULL) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()
From: Kees Cook > Sent: 13 March 2018 22:15 ... > I'll send a "const_max()" which will refuse to work on > non-constant-values (so it doesn't get accidentally used on variables > that could be exposed to double-evaluation), and will work for stack > array declarations (to avoid the overly-sensitive -Wvla checks). ISTR the definitions were of the form: char foo[max(sizeof (struct bah), sizeof (struct baz))]; This doesn't generate a 'foo' with the required alignment. It would be much better to use a union. David
RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Linus Torvalds > Sent: 16 March 2018 17:29 > On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer wrote: > > > > If you want to catch stack frames which have unbounded size, > > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant > > adjusted as needed) might be the better approach. > > No, we want to catch *variable* stack sizes. > > Does "-Werror=vla-larger-than=0" perhaps work for that? No, because > the stupid compiler says that is "meaningless". > > And no, using "-Werror=vla-larger-than=1" doesn't work either, because > the moronic compiler continues to think that "vla" is about the > _type_, not the code: > >t.c: In function ‘test’: >t.c:6:6: error: argument to variable-length array is too large > [-Werror=vla-larger-than=] > int array[(1,100)]; > > Gcc people are crazy. > > Is there really no way to just say "shut up about the stupid _syntax_ > issue that is entirely irrelevant, and give us the _code_ issue". I looked at the generated code for one of the constant sized VLA that the compiler barfed at. It seemed to subtract constants from %sp separately for the VLA. So it looks like the compiler treats them as VLA even though it knows the size. That is probably missing optimisation. David
RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus Torvalds > Sent: 18 March 2018 23:36 ... > > Yeah, and since we're in the situation that *new* gcc versions work > for us anyway, and we only have issues with older gcc's (that sadly > people still use), even if there was a new cool feature we couldn't > use it. Is it necessary to have the full checks for old versions of gcc? Even -Wvla could be predicated on very recent gcc - since we aren't worried about whether gcc decides to generate a vla, but whether the source requests one. David
RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Kees Cook
> Sent: 22 March 2018 15:01
...
> > /* Glory to Martin Uecker */
> > #define __is_constant(a) \
> > (sizeof(int) == sizeof(*(1 ? ((void*)((a) * 0l)) : (int*)1)))
...
> So, this time it's not a catastrophic failure with gcc 4.4. Instead it
> fails in 11 distinct places:
...
> Seems like it doesn't like void * arguments:
>
> mm/percpu.c:
> void *ptr;
> ...
> base = min(ptr, base);
Try adding (unsigned long) before the (a).
David
N�r��yb�X��ǧv�^�){.n�+{�n�߲)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
RE: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()
The amount of replicated defined could also be reduced by passing > or < to a min_max() macro. So you start off with something like: #define min(x, y) __min_max(x, <, y) #define max(x, y) __min_max(x, >, y) then have: #define __min_max(x, cond, y) ((x) cond (y) ? (x) : (y)) in all its associated flavours. David
