Theodore Ts'o ty...@mit.edu writes:
#undef __NR_syscalls
-#define __NR_syscalls 277
+#define __NR_syscalls 278
You need to add the syscall to kernel/sys_ni.c too, otherwise it will be
impossible to build without random device.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
One basic question... why limit this to /dev/random?
If we're trying to avoid fd exhaustion attacks, wouldn't an atomically
read a file into a buffer system call (that could be used on
/dev/urandom, or /etc/hostname, or /proc/foo, or...) be more useful?
E.g.
ssize_t readat(int dirfd, char const
In the end people would just recall getentropy in a loop and fetch 256
bytes each time. I don't think the artificial limit does make any sense.
I agree that this allows a potential misuse of the interface, but
doesn't a warning in dmesg suffice?
It makes their code not work, so they can are
On Sun, Jul 20, 2014 at 08:50:06AM -0700, Andi Kleen wrote:
Theodore Ts'o ty...@mit.edu writes:
#undef __NR_syscalls
-#define __NR_syscalls 277
+#define __NR_syscalls 278
You need to add the syscall to kernel/sys_ni.c too, otherwise it will be
impossible to build without random
On Sun, Jul 20, 2014 at 12:26:22PM -0400, George Spelvin wrote:
One basic question... why limit this to /dev/random?
If we're trying to avoid fd exhaustion attacks, wouldn't an atomically
read a file into a buffer system call (that could be used on
/dev/urandom, or /etc/hostname, or
Theodore Ts'o ty...@mit.edu writes:
ERRORS
EINVAL The buflen value was invalid.
Also on unknown flags? Without that it would be impossible to probe for
implemented flags.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3
On Sun, Jul 20, 2014 at 07:27:42PM +0200, Andreas Schwab wrote:
Theodore Ts'o ty...@mit.edu writes:
ERRORS
EINVAL The buflen value was invalid.
Also on unknown flags? Without that it would be impossible to probe for
implemented flags.
We removed the cap on the buflen size
On So, 2014-07-20 at 13:03 -0400, George Spelvin wrote:
In the end people would just recall getentropy in a loop and fetch 256
bytes each time. I don't think the artificial limit does make any sense.
I agree that this allows a potential misuse of the interface, but
doesn't a warning in
On Thu, Jul 17, 2014 at 01:01:16PM -0400, Theodore Ts'o wrote:
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system
From: Benoit Taine benoit.ta...@lip6.fr
Date: Fri, 18 Jul 2014 17:26:47 +0200
We should prefer `const struct pci_device_id` over
`DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
This issue was reported by checkpatch.
A simplified version of the semantic patch that makes
10 matches
Mail list logo