[PATCH] vfs: atomic f_pos access in llseek()

Commit 9c225f2655e36a4 (vfs: atomic f_pos accesses as per POSIX) changed several system calls to use fdget_pos() instead of fdget(), but missed sys_llseek(). Fix it. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/read_write.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

[PATCH] vfs: Don't let __fdget_pos() get FMODE_PATH files

to fail with ESPIPE rather than EBADF. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/file.c | 19 --- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/fs/file.c b/fs/file.c index 60a45e9..eb56a13 100644 --- a/fs/file.c +++ b/fs/file.c @@ -713,27 +713,16

[PATCH] vfs: Deduplicate code shared by xattr system calls operating on paths

() and lremovexattr() Despite this, the implementations all had duplicated code, so this commit redirects each of the above pairs of system calls to a corresponding function to which different lookup flags (LOOKUP_FOLLOW or 0) are passed. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/xattr.c | 116

[PATCH] aio: Fix type of iterator variable in do_io_submit()

). Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/aio.c b/fs/aio.c index 12a3de0e..4c96af7 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -1441,7 +1441,7 @@ long do_io_submit(aio_context_t ctx_id, long nr, { struct

Re: [PATCH] vfs: rw_copy_check_uvector() - free iov on error

The proposed patch doesn't work because in compat_rw_copy_check_uvector(), 'iov' is incremented in the loop before it is freed or returned. This probably should be changed to indexing with 'seg', like in the non-compat version... -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH] vfs: rw_copy_check_uvector() - free iov on error

On Wed, Apr 23, 2014 at 12:06:39AM -0500, Eric Biggers wrote: The proposed patch doesn't work because in compat_rw_copy_check_uvector(), 'iov' is incremented in the loop before it is freed or returned. This probably should be changed to indexing with 'seg', like in the non-compat version

Re: [PATCH] aio: Fix type of iterator variable in do_io_submit()

On Wed, Apr 23, 2014 at 10:42:37AM -0400, Benjamin LaHaise wrote: Practically speaking, this change has no effect. The io_submit() syscall will exit far before we even hit INT_MAX because of the limits on the number of iocbs. Yes it looks like it doesn't actually make a difference due to

[PATCH] vfs: fix check for fallocate on active swapfile

Fix the broken check for calling sys_fallocate() on an active swapfile, introduced by commit 0790b31b69374ddadefe (fs: disallow all fallocate operation on active swapfile). Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/open.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions

[BUG] fuse: request prepared before protocol version is known

I am using Linux 3.19-rc1 and I encountered a bug where stat() would sporatically fail with EIO when called on a file in a FUSE filesystem very shortly after that filesystem has been mounted. This is a regression caused by commit 7078187a: fuse: introduce fuse_simple_request() helper. The

[BUG] rtl8192se: panic accessing unmapped memory in skb

Hi, I have a RTL8192SE wireless card, attached via PCI. Usually it works with no issues, but I recently had a kernel panic occur in the rtl8192se driver. The kernel version is 3.18. Based on my analysis of the panic dump, the panic was caused by a memory access violation in this block of code

Re: [BUG] rtl8192se: panic accessing unmapped memory in skb

Hi, To get your patched version to work at all I had to update _rtl_pci_init_rx_ring() to account for new return value of _rtl_pci_init_one_rxdesc(). I will let you know if anything shows up in the kernel log, but I expect this is a highly sporadic problem. The system has 4 GB of memory, and I

fs/namei.c: Misuse of sequence counts?

Hi, I've been reading through the path lookup code and I believe there may have been bugs introduced by commit 4023bfc9 (be careful with nd-inode in path_init() and follow_dotdot_rcu()). And I may have found a pre-existing bug as well. In follow_dotdot_rcu(), said commit moved loads of the inode

Re: fs/namei.c: Misuse of sequence counts?

On Sun, Oct 12, 2014 at 12:46:35AM +0100, Al Viro wrote: Nope. What we do is * pick parent inode and seqcount (in whatever order) * THEN check that child is still unchanged. The second part guarantees that parent dentry had been the parent of child all along, since the moment

Re: fs/namei.c: Misuse of sequence counts?

On Sun, Oct 12, 2014 at 01:12:59AM +0100, Al Viro wrote: Huh? What's to guarantee that dentry hasn't become negative since the moment we'd fetched the seqcount? _That_ is the problem we are dealing with here - link_path_walk() relies on nd-inode being non-NULL. Hmm, I guess that makes

Re: fs/namei.c: Misuse of sequence counts?

On Sun, Oct 12, 2014 at 05:37:37AM +0100, Al Viro wrote: Gets clumsy in set_root_rcu() - you do *not* want it to bugger nd-inode when done by follow_dotdot_rcu(), so we'd need either some indication which caller it is, or something like struct inode **inode in argument list, with NULL passed

Re: fs/namei.c: Misuse of sequence counts?

Here's a patch for reference (untested): diff --git a/fs/namei.c b/fs/namei.c index a7b05bf..84704e4 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -649,17 +649,15 @@ static __always_inline void set_root(struct nameidata *nd) static int link_path_walk(const char *, struct nameidata *); -static

[PATCH] kernel/groups.c: Code simplifications

Reduce nesting and simplify the control flow, remove redundant 'gidsetsize 0' check in sys_getgroups(), and inline groups_to_user(). This patch reduces the length of kernel/groups.c by 27 lines. Signed-off-by: Eric Biggers ebigge...@gmail.com --- kernel/groups.c | 69

[PATCH] vfs: Deduplicate code shared by xattr system calls operating on paths

. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/xattr.c | 116 + 1 file changed, 39 insertions(+), 77 deletions(-) diff --git a/fs/xattr.c b/fs/xattr.c index c69e6d4..64e83ef 100644 --- a/fs/xattr.c +++ b/fs/xattr.c @@ -364,13

[PATCH] fs/file_table.c: Update alloc_file() comment

This comment is 5 years outdated; init_file() no longer exists. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/file_table.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/fs/file_table.c b/fs/file_table.c index 0bab12b..3f85411 100644 --- a/fs

[PATCH 1/5] fs/anon_inodes.c: Remove unnecessary IS_ERR(anon_inode_inode)

anon_inode_inode is allocated by anon_inode_init(), which is fs_initcall and will panic if it couldn't be allocated. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/anon_inodes.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index 80ef38c

[PATCH 3/5] fs/anon_inodes.c: Mark anon_inode_inode __read_mostly

At least, for consistency with anon_inode_mnt. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/anon_inodes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index 268153a..444a705 100644 --- a/fs/anon_inodes.c +++ b/fs/anon_inodes.c

[PATCH 2/5] fs/anon_inodes.c: Simplify control flow in anon_inode_getfd()

Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/anon_inodes.c | 18 ++ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index 1faff09..268153a 100644 --- a/fs/anon_inodes.c +++ b/fs/anon_inodes.c @@ -136,26 +136,20

[PATCH 4/5] fs/anon_inodes.c: Remove unneeded #includes

Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/anon_inodes.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index 444a705..bbfa038 100644 --- a/fs/anon_inodes.c +++ b/fs/anon_inodes.c @@ -8,10 +8,7 @@ * */ -#include linux/cred.h #include

[PATCH 5/5] fs/anon_inodes.c: Remove incorrect information in comment

Dentries for the anonymous inode are *not* named based on the inode sequence number. Signed-off-by: Eric Biggers ebigge...@gmail.com --- fs/anon_inodes.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index bbfa038..ee81409 100644

[PATCH] drivers: Update help for firmware loading options

Update the help text to account for the fact that the kernel can now load firmware directly from the filesystem. Also clarify how the FW_LOADER option works. Signed-off-by: Eric Biggers ebigge...@gmail.com --- drivers/base/Kconfig | 33 + 1 file changed, 21

Re: [Linux v4.3-rc6] i915: issues with Skylake integrated graphics

On Mon, Oct 26, 2015 at 03:28:37PM +0200, Jani Nikula wrote: > Please file two separate bugs at [1], one for the above, and another for > the below. Please add drm.debug=14 module parameter, and attach dmesg > all the way from boot to the problem. I have filed

[Linux v4.3-rc6] i915: issues with Skylake integrated graphics

Hi, I am testing Linux v4.3-rc6 on a laptop with Intel 'Skylake' integrated graphics. The integrated display works, but I noticed several warnings in the kernel log, and a VGA monitor attached to the HDMI input via a VGA->HDMI adapter did not work. Furthermore, the system hung for several

Re: [PATCH] vfs: clear remainder of 'full_fds_bits' in dup_fd()

Here's the revised patch: vfs: clear remainder of 'full_fds_bits' in dup_fd() This fixes a bug from commit f3f86e33dc3d ("vfs: Fix pathological performance case for __alloc_fd()"). v2: refactor to share fd bitmap copying code Signed-off-by: Eric Biggers <ebigge...@gmail.com>

Re: [PATCH] vfs: clear remainder of 'full_fds_bits' in dup_fd()

On Thu, Nov 05, 2015 at 08:15:49PM -0800, Linus Torvalds wrote: > Would you mind doing that version of the patch instead? I can do it > too, but I'd rather give authorship to you, since you found the stupid > issue, which is actually the much bigger deal. Sure, I'll try it that way and see what

[PATCH] vfs: clear remainder of 'full_fds_bits' in dup_fd()

This fixes a bug from commit f3f86e33dc3d ("vfs: Fix pathological performance case for __alloc_fd()"). Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/file.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/fs/file.c b/fs/file

[PATCH 1/2] fs/pipe.c: preserve alloc_file() error code

.gmane.org/gmane.linux.kernel/1357942 Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/pipe.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/pipe.c b/fs/pipe.c index 8865f79..997de34 100644 --- a/fs/pipe.c +++ b/fs/pipe.c @@ -693,17 +693,20 @@ int create_pipe_f

[PATCH 2/2] fs/pipe.c: return error code rather than 0 in pipe_write()

data[1] = {0}; assert(0 == pipe(fd)); assert(1 == write(fd[1], data, 1)); /* prior to this patch, write() returned 0 here */ assert(-1 == write(fd[1], NULL, 1)); assert(errno == EFAULT); } Signed-off-by: Eric Bi

[PATCH] userfaultfd: add missing mmput() in error path

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/userfaultfd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 634e676..f9aeb40 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1287,8 +1287,10 @@ static struc

Re: [PATCH] drivers: Update help for firmware loading options

On Sun, Oct 04, 2015 at 08:14:16PM +0100, Greg KH wrote: > > Are you sure? I think this should stay as "Userspace..." as that is > what it does, right? > > Turning it off should only drop the userspace callouts, it shouldn't > stop the kernel from loading firmware from the filesystem all on its

[PATCH RESEND] drivers: Update help for firmware loading options

Update the help text to account for the fact that the kernel can now load firmware directly from the filesystem. Also clarify how the FW_LOADER option works. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- drivers/base/Kconfig | 33 + 1 file chang

[PATCH] dcache: Deduplicate code that sets up dentry_hashtable

to by 'dentry_hashtable' might alias 'd_hash_shift'. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/dcache.c | 48 +++- 1 file changed, 19 insertions(+), 29 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 5c33aeb..7cfe848 100644 --- a/fs/dc

[PATCH] misc: mic: fix incorrect use of error codes in SCIF DMA driver

The error code passed to ERR_PTR() always should be negated. Also, the return value of scif_add_mmu_notifier() was never checked. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- drivers/misc/mic/scif/scif_dma.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-)

[PATCH] netfilter: nft_ct: define nft_ct_get_eval_counter() only when needed

This eliminates an "unused function" compiler warning when CONFIG_NF_CONNTRACK_LABELS is not defined. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- net/netfilter/nft_ct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct

[PATCH] PM: declare __tracedata symbols as char[] rather than char

this by declaring the symbols as arrays. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- drivers/base/power/trace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a311cfa..a697579 100644 --- a/driver

Out-of-bounds array index in acpi_ds_create_operand()

Hi, When booting Linux 4.5-rc1 with UBSAN enabled, I see the following report of undefined behavior: [0.675383] [0.675387] UBSAN: Undefined behaviour in drivers/acpi/acpica/dsutils.c:641:16 [0.675390]

[PATCH] cpumask: remove incorrect information from comment

Since commit cdfdef75e795f ("cpumask: only allocate nr_cpumask_bits."), this comment above cpumask_size() is no longer relevant. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- include/linux/cpumask.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/cpu

[PATCH] cpufreq: simplify for_each_suitable_policy() macro

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- drivers/cpufreq/cpufreq.c | 44 +++- 1 file changed, 3 insertions(+), 41 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index e979ec7..3aa7b2b 100644 --- a/d

[PATCH] cpufreq: fix comment about return value of cpufreq_register_driver()

The comment has been incorrect since commit 4dea5806d332 ("cpufreq: return EEXIST instead of EBUSY for second registering"). Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- drivers/cpufreq/cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

[PATCH] vfs: constify arguments to utime family of system calls

The system calls to set file times: utime(), utimes(), futimesat(), and utimensat(), all take in pointers to a filename and time information, neither of which is modified. Mark the pointed-to data as 'const' to better reflect the semantics. Signed-off-by: Eric Biggers <ebigge...@gmail.

Re: [GIT PULL] f2fs updates for v4.6

Why was the XTS tweak initialization changed in commit 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto")? Old code: memcpy(xts_tweak, , sizeof(index)); memset(_tweak[sizeof(index)], 0, F2FS_XTS_TWEAK_SIZE - sizeof(index)); New

Re: [GIT PULL] f2fs updates for v4.6

esn't make the on-disk format of the filesystem endianness-dependent? I thought that's a big no-no. On Sat, Mar 26, 2016 at 01:56:06AM -0700, Jaegeuk Kim wrote: > On Sat, Mar 26, 2016 at 01:10:07AM -0500, Eric Biggers wrote: > > Why was the XTS tweak initialization changed in commit 0b81d07790

Bloat caused by unnecessary calls to compound_head()?

Hi, I noticed that after the recent "page-flags" patchset, there are an excessive number of calls to compound_head() in certain places. For example, the frequently executed mark_page_accessed() function already starts out by calling compound_head(), but then each time it tests a page flag

A few more filesystem encryption questions

Hello, A few more questions about the new filesystem encryption code: I found that a process without access to the master encryption key can read a file's full decrypted contents, provided that the file was opened recently by a process with access to the key. This is true even if the privileged

[PATCH 13/13] fscrypto: improve error handling in fscrypt_set_policy()

In some cases, the previous code did not correctly propagate errors to the caller. Also, only one call to ->get_context() is required. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/policy.c | 64 +- 1 file ch

[PATCH 03/13] fscrypto: rename functions to load and unload inode encryption info

names better reflect the actual behavior where the "load" function just loads the fscrypt_info into i_crypto_info; it doesn't actually return it to the caller. There is also no reference counting involved, as might be suggested by the verbs "get" and "put". Signed-off-by:

[PATCH 07/13] fscrypto: simplify building key descriptor string

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/keyinfo.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c index cb06351..5fcee4d 100644 --- a/fs/crypto/keyinfo.c +++ b/fs/crypto/keyinfo.c @@ -164,13

[PATCH 11/13] fscrypto: restrict setting encryption policy to inode owner

files in their own directory. Fix this by requiring inode_owner_or_capable() permission to set an encryption policy. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/policy.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index c

[PATCH 12/13] fscrypto: require write access to mount to set encryption policy

Since setting an encryption policy requires writing data to the filesystem, it should be guarded by mnt_want_write/mnt_drop_write. Otherwise, a user could cause a write to a readonly or frozen filesystem. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/policy.c

[PATCH 09/13] fscrypto: make fname_encrypt() actually return length of ciphertext

This makes the return value match the comment. Previously it would actually return 0 if encryption was successful. (No callers currently care.) Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/fname.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --gi

[PATCH 06/13] fscrypto: crypto_alloc_skcipher() always returns an ERR_PTR(), never NULL

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/keyinfo.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c index 33296c0..cb06351 100644 --- a/fs/crypto/keyinfo.c +++ b/fs/crypto/keyinfo.c @@ -208,8 +208,8 @@

[PATCH 01/13] fscrypto: remove unnecessary includes

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/crypto.c | 1 - fs/crypto/fname.c | 2 -- fs/crypto/keyinfo.c | 3 --- 3 files changed, 6 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 06cd1a2..2c7923d 100644 --- a/fs/crypto/crypto.c +++ b/fs/

[PATCH 05/13] fscrypto: comment improvements and fixes

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/crypto.c | 13 ++-- fs/crypto/fname.c| 33 ++ fs/crypto/keyinfo.c | 8 include/linux/fscrypto.h | 53 ++-- 4 files c

[PATCH 02/13] fscrypto: rename some functions for clarity

fscrypt_process_policy() to fscrypt_set_policy(). The new name better matches the ioctl, and it goes along with fscrypt_get_policy(). Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/crypto.c | 11 ++- fs/crypto/fname.c| 11 +++ fs/crypto/policy.c

[PATCH 00/13] fscrypto: cleanups and fixes

This patchset includes various cleanups for the new filesystem encryption code as well as some bug fixes for the FS_IOC_SET_ENCRYPTION_POLICY ioctl. Eric Biggers (13): fscrypto: remove unnecessary includes fscrypto: rename some functions for clarity fscrypto: rename functions to load

[PATCH 04/13] fscrypto: return bool instead of int where appropriate

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/policy.c | 24 include/linux/fscrypto.h | 12 ++-- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index 03a2f50..93244b5 100644 --

[PATCH 10/13] fscrypto: restrict setting new policy to empty files and directories only

to be created for empty regular files and directories. For a correct solution, it is necessary to conduct the operation under the inode lock; otherwise the inode's size might be changed concurrently. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/policy.

[PATCH 08/13] fscrypto: use standard macros from kernel.h

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- fs/crypto/fname.c | 17 + 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c index cd0eae8..e5c6959 100644 --- a/fs/crypto/fname.c +++ b/fs/crypto/fname.c @@ -14,11

[PATCH] lib/Kconfig.debug: fix typo in help for new option

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 1e9a607..e6071ba 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1486,7 +1486,7 @@

[PATCH v2] vfs: constify arguments to utime family of system calls

The system calls to set file times: utime(), utimes(), futimesat(), and utimensat(), all take in pointers to a filename and time information, neither of which is modified. Mark the pointed-to data as 'const' to better reflect the semantics. Signed-off-by: Eric Biggers <ebigge...@gmail.

Re: [PATCH v2] vfs: constify arguments to utime family of system calls

On Fri, Apr 01, 2016 at 03:05:24AM +0100, Al Viro wrote: > On Thu, Mar 31, 2016 at 08:51:12PM -0500, Eric Biggers wrote: > > The system calls to set file times: utime(), utimes(), futimesat(), and > > utimensat(), all take in pointers to a filename and time information, >

[PATCH] random: properly align get_random_int_hash

get_random_long() reads from the get_random_int_hash array using an unsigned long pointer. For this code to be guaranteed correct on all architectures, the array must be aligned to an unsigned long boundary. Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- drivers/char/random.c | 4 +

Re: Bloat caused by unnecessary calls to compound_head()?

On Sun, Mar 27, 2016 at 10:46:49PM +0300, Kirill A. Shutemov wrote: > The idea is to introduce new type to indicate head page -- > 'struct head_page' -- it's compatible with struct page on memory layout, > but distinct from C point of view. compound_head() should return pointer > of that type. For

[PATCH] crypto: document correct return value for request allocation

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- Documentation/DocBook/crypto-API.tmpl | 6 +++--- include/crypto/aead.h | 3 +-- include/crypto/hash.h | 3 +-- include/crypto/skcipher.h | 3 +-- include/linux/crypto.h| 3

Legal characters in encrypted fscrypto (f2fs/ext4) filename?

Hello, While reviewing the new filesystem encryption code, I was confused by the intended set of legal characters in the printable form of an encrypted filename. According to the actual code in fs/crypto/fname.c, the legal characters are: a-zA-Z0-9+, Alternatively, according to the

Re: [PATCH] ext4 crypto: migrate into vfs's crypto engine

Hi Jaegeuk, On Mon, Apr 25, 2016 at 05:15:36PM -0700, Jaegeuk Kim wrote: > This patch removes the most parts of internal crypto codes. > And then, it modifies and adds some ext4-specific crypt codes to use the > generic > facility. Except for the key name prefix issue that Ted pointed out, this

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote: > > Today, I did zram-lz4 performance test with fio in current mmotm and > found it makes regression about 20%. > This may or may not be the cause of the specific regression you're observing, but I just noticed that the proposed patch

Re: [kernel-hardening] [PATCH v2 2/2] fork: make number of cached stacks (vmapped) configurable using Kbuild

On Thu, Feb 09, 2017 at 01:03:47PM +0900, Hoeun Ryu wrote: > +config NR_VMAP_STACK_CACHE > + int "Number of cached stacks" > + default "2" > + depends on VMAP_STACK > + help > + This determines how many stacks can be cached for virtually > + mapped kernel stacks. > +

Re: [kernel-hardening] [PATCH v2 1/2] fork: free vmapped stacks in cache when cpus are offline

Hi Hoeun, On Thu, Feb 09, 2017 at 01:03:46PM +0900, Hoeun Ryu wrote: > +static int free_vm_stack_cache(unsigned int cpu) > +{ > + int i; > + > + for (i = 0; i < NR_CACHED_STACKS; i++) { > + struct vm_struct *vm_stack = this_cpu_read(cached_stacks[i]); > + if

Re: [PATCH v5 0/5] Update LZ4 compressor module

On Thu, Jan 26, 2017 at 08:57:30AM +0100, Sven Schmidt wrote: > > This patchset is for updating the LZ4 compression module to a version based > on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast > which provides an "acceleration" parameter as a tradeoff between > high

[PATCH] fscrypt: remove broken support for detecting keyring key revocation

From: Eric Biggers <ebigg...@google.com> Filesystem encryption ostensibly supported revoking a keyring key that had been used to "unlock" encrypted files, causing those files to become "locked" again. This was, however, buggy for several reasons, the most severe

[PATCH 2/2] crypto: testmgr - constify all test vectors

From: Eric Biggers <ebigg...@google.com> Cryptographic test vectors should never be modified, so constify them to enforce this at both compile-time and run-time. This moves a significant amount of data from .data to .rodata when the crypto tests are enabled. Signed-off-by: Eric Biggers

[PATCH 1/2] crypto: kpp - constify buffer passed to crypto_kpp_set_secret()

From: Eric Biggers <ebigg...@google.com> Constify the buffer passed to crypto_kpp_set_secret() and kpp_alg.set_secret, since it is never modified. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/dh.c | 3 ++- c

[PATCH 0/2] crypto: constify test vectors

From: Eric Biggers <ebigg...@google.com> These two patches mark all the cryptographic test vectors as 'const'. This has several potential advantages and moves a large amount of data from .data to .rodata when the tests are enabled. The second patch does the real work; the first just pr

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote: > > > > [Also, for some reason linux-crypto is apparently still not receiving patch > > 1/5 > > in the series. It's missing from the linux-crypto archive at > > http://www.spinics.net/lists/linux-crypto/, so it's not just me.] > > >

Re: [PATCH v7 0/5] Update LZ4 compressor module

Also I noticed another bug, this time in LZ4_count(): > #if defined(CONFIG_64BIT) > #define LZ4_ARCH64 1 > #else > #define LZ4_ARCH64 0 > #endif ... > #ifdef LZ4_ARCH64 >if ((pIn < (pInLimit-3)) >&& (LZ4_read32(pMatch) == LZ4_read32(pIn))) { >pIn += 4;

Re: [PATCH] lz4: fix performance regressions

Hi Sven, On Sun, Feb 12, 2017 at 12:16:18PM +0100, Sven Schmidt wrote: > /*- > * Reading and writing into memory > **/ > +typedef union { > + U16 u16; > + U32 u32; > + size_t uArch; > +} __packed unalign; >

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 12:05:40PM +0100, Sven Schmidt wrote: > > Because of how LZ4_ARCH64 is defined, it needs to be '#if LZ4_ARCH64'. > > > > But I also think the way upstream LZ4 does 64-bit detection could have just > > been > > left as-is; it has a function which gets inlined: > > > >

Re: [PATCH 3.14 14/46] random: properly align get_random_int_hash

.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Eric Biggers <ebigge...@gmail.com> > > commit b1132deac01c2332d234fa821a70022796b79182 upstream. > > get_random_long() reads from the get_random_int_hash array

[PATCH] mm: avoid undefined behavior in hardened usercopy check

tools checking for undefined behavior. Signed-off-by: Eric Biggers <ebigg...@google.com> --- mm/usercopy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/usercopy.c b/mm/usercopy.c index 8ebae91..82f81df 100644 --- a/mm/usercopy.c +++ b/mm/usercopy.c @@ -124,7 +124

[PATCH] crypto: doc - fix documentation for bulk registration functions

Update the documentation for crypto_register_algs() and crypto_unregister_algs() to match the actual behavior. Signed-off-by: Eric Biggers <ebigg...@google.com> --- Documentation/DocBook/crypto-API.tmpl | 38 --- 1 file changed, 26 insertions(+), 12 del

[PATCH] blockgroup_lock.h: remove debris from bgl_lock_ptr() conversion

An obsolete comment and extra parentheses were left over from when the sb_bgl_lock() macro was replaced with the bgl_lock_ptr() function. Signed-off-by: Eric Biggers <ebigg...@google.com> --- include/linux/blockgroup_lock.h | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff

[PATCH] blockgroup_lock.h: simplify definition of NR_BG_LOCKS

We can use ilog2() to more easily produce the desired NR_BG_LOCKS. This works because ilog2() is evaluated at compile-time when its argument is a compile-time constant. I did not change the chosen NR_BG_LOCKS values. Signed-off-by: Eric Biggers <ebigg...@google.com> --- include

[PATCH] fs/buffer.c: make __getblk_slow() static

__getblk_slow() was exported to modules in commit 3b5e6454aaf6 ("fs/buffer.c: support buffer cache allocations with gfp modifiers"). This seems to have been a mistake, as no users were introduced nor was the function declared in a header. Change it back to 'static'. Signed-off-by: Er

Re: [PATCH] ext4: Check for encryption feature before fscrypt_process_policy()

On Thu, Sep 22, 2016 at 06:38:03PM -0400, Theodore Ts'o wrote: > > I think it's fine to fix it now in upstream. It might cause some > problems for Cyanogen developers if they want to try to use an > upstream kernel and also enable the ext4 encryption feature, but the > fix to make_ext4fs isn't

[PATCH] ACPI / EC: Fix unused function warning when CONFIG_PM_SLEEP=n

Signed-off-by: Eric Biggers <ebigg...@google.com> --- drivers/acpi/ec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 6805310..48e19d0 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -526,6 +526,7 @@ static void acpi_ec_enable

Re: Locking rules for fscrypt_operations->set_context()

On Tue, Sep 20, 2016 at 04:30:06PM +0200, Richard Weinberger wrote: > Hi! > > To my understanding ->setxattr() is always being called with i_mutex held. > ->set_context() in ext4 stores the security context using ext4_xattr_set(), > but the fs crypto framework does not lock the inode itself. >

Re: [PATCH] ext4: Check for encryption feature before fscrypt_process_policy()

On Thu, Sep 22, 2016 at 08:50:54AM +0200, Richard Weinberger wrote: > ...otherwise an user can enable encryption for certain files even > when the filesystem is unable to support it. > Such a case would be a filesystem created by mkfs.ext4's default > settings, 1KiB block size. Ext4 supports

Re: [PATCH] crypto: cmac - fix alignment of 'consts'

On Mon, Oct 10, 2016 at 10:51:14AM -0700, Joe Perches wrote: > > Hey Eric. > > I don't see any PTR_ALIGN uses in crypto/ or drivers/crypto/ that > use a bitwise or, just mask + 1, but I believe the effect is the > same. Anyway, your choice, but I think using min is clearer. > > cheers, Joe

[PATCH] crypto: cmac - return -EINVAL if block size is unsupported

ons. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/cmac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/cmac.c b/crypto/cmac.c index 7a8bfbd..b6c4059 100644 --- a/crypto/cmac.c +++ b/crypto/cmac.c @@ -243,6 +243,7 @@ static int cmac_create(struct crypto_templ

[PATCH] crypto: cmac - fix alignment of 'consts'

The per-transform 'consts' array is accessed as __be64 in crypto_cmac_digest_setkey() but was only guaranteed to be aligned to __alignof__(long). Fix this by aligning it to __alignof__(__be64). Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/cmac.c | 13 +

Re: [PATCH] crypto: cmac - fix alignment of 'consts'

On Mon, Oct 10, 2016 at 10:29:55AM -0700, Joe Perches wrote: > On Mon, 2016-10-10 at 10:15 -0700, Eric Biggers wrote: > > The per-transform 'consts' array is accessed as __be64 in > > crypto_cmac_digest_setkey() but was only guaranteed to be aligned to > > __alignof__(long).

[PATCH] ext4: do not advertise encryption support when disabled

the ext4 feature files are all hardcoded to have a contents of "supported", it really is the presence or absence of the file that is significant, not the contents (and this change reflects that). Signed-off-by: Eric Biggers <ebigg...@google.com> --- fs/ext4/sysfs.c | 4 1

Re: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access

On Tue, Nov 08, 2016 at 08:52:39AM +0100, Martin Willi wrote: > > > Not sure what the exact alignment rules for key/iv are, but maybe we > want to replace the same function in chacha20_generic.c as well? > > Martin chacha20-generic provides a blkcipher API and sets an alignmask of sizeof(u32)

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Mon, Nov 07, 2016 at 07:08:22PM +0100, Jason A. Donenfeld wrote: > Hmm... The general data flow that strikes me as most pertinent is > something like: > > struct sk_buff *skb = get_it_from_somewhere(); > skb = skb_share_check(skb, GFP_ATOMIC); > num_frags = skb_cow_data(skb, ..., ...); >

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Mon, Nov 07, 2016 at 08:02:35PM +0100, Jason A. Donenfeld wrote: > On Mon, Nov 7, 2016 at 7:26 PM, Eric Biggers <ebigg...@google.com> wrote: > > > > I was not referring to any users in particular, only what users could do. > > As an > > example, if you did

  1   2   3   4   5   6   7   8   9   10   >