[PATCH] eHEA: Don't do memory allocation under lock if not necessary

In ehea_probe_adapter() the initial memory allocation and initialisation does not need to be done with the ehea_fw_handles.lock semaphore held. Doing so extends the amount of time the lock is held unnecessarily. Signed-off-by: David Howells dhowe...@redhat.com --- drivers/net/ehea/ehea_main.c

[PATCH] eHEA: Don't do memory allocation under lock if not necessary

In ehea_probe_adapter() the initial memory allocation and initialisation does not need to be done with the ehea_fw_handles.lock semaphore held. Doing so extends the amount of time the lock is held unnecessarily. Signed-off-by: David Howells dhowe...@redhat.com --- drivers/net/ehea/ehea_main.c

Re: [PATCH 1/3] Fix Unlikely(x) == y

Geert Uytterhoeven [EMAIL PROTECTED] wrote: Hence shouldn't we ask the gcc people what's the purpose of __builtin_expect(), if it doesn't live up to its promise? __builtin_expect() is useful on FRV where you _have_ to give each branch and conditional branch instruction a measure of probability

Re: [RFC 05/10] mn10300: vmlinux.lds.S cleanup - use PAGE_SIZE, PERCPU macroses

instead of explicit section definition Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED] Acked-by: David Howells [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations

resource check at (4) and (6) that ignores IORESOURCE_ROM_ENABLE Both parts: Acked-by: David Howells [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 01/16] PCI: add generic pci_enable_resources()

. This version is based on powerpc, which seemed most up-to-date. The only functional difference from the x86 version is that this uses !r-parent to check for resource collisions instead of !r-start r-end. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Acked-by: David Howells [EMAIL PROTECTED

Re: [patch 05/16] frv: use generic pci_enable_resources()

IORESOURCE_MEM set - skips ROM resources unless IORESOURCE_ROM_ENABLE is set - checks for resource collisions with !r-parent Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Acked-by: David Howells [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc

Re: [patch 08/16] mn10300: use generic pci_enable_resources()

IORESOURCE_MEM set - skips ROM resources unless IORESOURCE_ROM_ENABLE is set - checks for resource collisions with !r-parent Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Acked-by: David Howells [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc

Re: [PATCH] powerpc/pseries/xcis: ansify

Al Viro [EMAIL PROTECTED] wrote: Signed-off-by: Al Viro [EMAIL PROTECTED] Acked-by: David Howells [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Fix build errors when BLOCK=n

Try the attached. David --- [PATCH] VFS: Make BSG declarations dependent on CONFIG_BLOCK From: David Howells [EMAIL PROTECTED] Make BSG function declarations dependent on CONFIG_BLOCK as they are not compilable if the block layer is compiled out. Signed-off-by: David Howells [EMAIL PROTECTED

Re: [PATCH 5/7] arch/powerpc/kernel: Use set_cpus_allowed_ptr

Julia Lawall ju...@diku.dk wrote: The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) That URL doesn't appear to work: Not Found The requested URL /) was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an

Re: [PATCH 5/7] arch/powerpc/kernel: Use set_cpus_allowed_ptr

David Howells dhowe...@redhat.com wrote: The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) That URL doesn't appear to work: Not Found The requested URL /) was not found on this server. Additionally, a 404 Not Found error was encountered while trying

Re: [PATCH v21 001/100] eclone (1/11): Factor out code to allocate pidmap page

With a huge patch series like this, can you post a cover note at the front (usually patch 0) saying what the point of the whole series is? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] PPC: Fix zero length strncmp() on powerpc

(GPL); MODULE_DESCRIPTION(Probe strncmp() bug); It should return error No anode on success and I/O error on failure. The module will not be retained. Signed-off-by: David Howells dhowe...@redhat.com --- arch/powerpc/lib/string.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions

Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration

K.Prasad pra...@linux.vnet.ibm.com wrote: My understanding is weak function definitions must appear in a different C file than their call sites to work on some toolchains. Atleast, there are quite a few precedents inside the Linux kernel for __weak functions being invoked from the file

Re: inline assembly

Scott Wood [EMAIL PROTECTED] wrote: int tmp; asm volatile(addi %1, %2, -1; andc %1, %2, %1; cntlzw %1, %1; subfic %0, %1, 31 : =r (j), =r (tmp) : r (i)); Registers are usually assumed to be 'long' in size, so I'd recommend using that rather than

Re: [2.6 patch] asm/ptrace.h userspace headers cleanup

... - don't expose function prototypes and macros to userspace: ... - mn10300 Acked-by: David Howells [EMAIL PROTECTED] (FRV and MN10300) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: checkpatch nits ...

Kevin Diggs [EMAIL PROTECTED] wrote: The entire block is: __asm__ __volatile__ ( addi %0,%3,-1\n andc %1,%3,%0\n cntlzw %1,%1\n subfic %1,%1,31\n cntlzw %0,%2\n: =r(cntlz), =r(cnttz):

[PATCH] PPC: Fix rtas_log_read()

rtas_log_size is invalidated when rtasd_log_lock is dropped or if it is not held. It is not correct to rely on userspace doing the right thing by assuming only one userspace process (rtasd) will be attempting read at any one time. Signed-off-by: David Howells [EMAIL PROTECTED] --- arch/powerpc

Re: [PATCH] powerpc: Fix integer constant warning

Steve Best sfb...@us.ibm.com wrote: -#define KERNELBASE (0xc000) +#define KERNELBASE (0xc000ULL) Is this the right fix? The code producing the warning is subtracting 0xc000 from a 32-bit number: naca = ntohl(*((u_int32_t*) inbuf[0x0C])) -

Re: [PATCH] powerpc: Fix integer constant warning

Josh Boyer jwbo...@linux.vnet.ibm.com wrote: It might not matter, since Paul sent a patch to remove this file entirely. Yeah, I saw that after... David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [PATCH] sched: fix spelling of sibling

Michael Neuling mi...@neuling.org wrote: No logic changes, only spelling. Signed-off-by: Michael Neuling mi...@neuling.org Acked-by: David Howells dhowe...@redhat.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

Re: Memory Mapping a char array in User Space

Ravi Gupta dceravigu...@gmail.com wrote: My device gets memory map successfully but when I tried to read from it I get garbage value. Is there something that I am missing? For starters, you really should allocate a page for your buffer rather than using kernel static data. mmap() allows

[PATCH 14/17] Fix powerpc irqflags

This (sub)patch is separated out for reviewing purposes. Once ACK'd it will need to be rolled into the main patch. Cc: b...@kernel.crashing.org Cc: pau...@samba.org Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/include/asm/hw_irq.h| 113 --

Re: [patch] mutex: optimise generic mutex implementations

hardware for it. Acked-by: David Howells [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Re[2]: [PATCH] fork_init: fix division by zero

Yuri Tikhonov [EMAIL PROTECTED] wrote: Here we believe in preprocessor: since all PAGE_SIZE, 8, and THREAD_SIZE are the constants we expect it will calculate this. The preprocessor shouldn't be calculating this. I believe it will _only_ calculate expressions for #if. In the situation

Re: Re[2]: [PATCH] fork_init: fix division by zero

David Howells [EMAIL PROTECTED] wrote: Ummm... On powerpc, I believe rotate-left would be a division as it does the bit-numbering and the bit direction the opposite way to more familiar CPUs such as x86. Actually, I'm not sure that's true. Sometimes powerpc makes my head hurt:-) David

[PATCH] NOMMU: Rename PowerPC's struct vm_region

or regions of memory mapped devices, such as flash. It is also used to retain copies of file content so that shareable private memory mappings of files can be made. As such, it may be compatible with what is described in the banner comment for PowerPC's vm_region struct. Signed-off-by: David Howells

Re: [PATCH] NOMMU: Rename PowerPC's struct vm_region

Josh Boyer [EMAIL PROTECTED] wrote: Is there a reason you renamed all the function names as well when they are static? Well, static functions can still conflict with a function of the same name that's declared globally in a header file, but mainly because M-x replace-string doesn't

Re: [PATCH] powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig]

9ffc93f203c18a70623f21950f1dd473c9ec48cd Remove all #inclusions of asm/system.h Add the debug header which contains powerpc_debugfs_root. Cc: David Howells dhowe...@redhat.com Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com Acked-by: David Howells dhowe...@redhat.com

[PATCH 10/26] fsl_udc: Don't use create_proc_read_entry() [RFC]

Don't use create_proc_read_entry() as that is deprecated, but rather use proc_create_data() and seq_file instead. Signed-off-by: David Howells dhowe...@redhat.com cc: Li Yang le...@freescale.com cc: Felipe Balbi ba...@ti.com cc: Greg Kroah-Hartman gre...@linuxfoundation.org cc: linux

[PATCH 04/28] proc: Supply PDE attribute setting accessor functions [RFC]

Supply accessor functions to set attributes in proc_dir_entry structs. The following are supplied: proc_set_size() and proc_set_user(). Signed-off-by: David Howells dhowe...@redhat.com cc: linuxppc-dev@lists.ozlabs.org cc: linux-me...@vger.kernel.org cc: net...@vger.kernel.org cc: linux-wirel

[PATCH 22/28] ppc: Clean up rtas_flash driver somewhat [RFC]

based on the filename. Instead provide separate file ops and split the function. Whilst we're at it, tabulate the procfile information and loop through it when creating or destroying them rather than manually coding each one. Signed-off-by: David Howells dhowe...@redhat.com cc: Benjamin

[PATCH 23/28] ppc: Clean up scanlog [RFC]

a destructor). Signed-off-by: David Howells dhowe...@redhat.com cc: Benjamin Herrenschmidt b...@kernel.crashing.org cc: Paul Mackerras pau...@samba.org cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/platforms/pseries/scanlog.c | 29 +++-- 1 file changed, 11 insertions(+), 18

Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young

Peter Zijlstra pet...@infradead.org wrote: What should nommu do anyways ? it's not like there's much it can do right ? It should never even hit the fault path to start with ... Something like the below makes a nommu arm config build.. David, is this indeed the correct thing to do for

Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young

-by: David Howells dhowe...@redhat.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: roundup_pow_of_two() may not handle 64-bit integers

Brian Norris computersforpe...@gmail.com wrote: I'm looking to use roundup_pow_of_two() (actually, order_base_2()) from linux/log2.h, but it seems that it only supports 64-bit integers if your toolchain uses a 64-bit 'unsigned long' type. This is strange, considering that ilog2() is

Re: [PATCH] atomic: add *_dec_not_zero

want to use this macro. Reported-by: David S. Miller da...@davemloft.net Signed-off-by: Sven Eckelmann s...@narfation.org Acked-by: David Howells dhowe...@redhat.com [MN10300 and FRV] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

[GIT PULL] Disintegrate UAPI for powerpc

-headers.git disintegrate-powerpc for you to fetch changes up to d4b1059feb6486ae0800e936b9dd5fd4e05b9d0c: UAPI: (Scripted) Disintegrate arch/powerpc/include/asm (2012-10-04 18:21:17 +0100) David Howells (6): UAPI: Fix the guards

[GIT PULL] Disintegrate UAPI for powerpc [ver #2]

/include/asm (2012-10-09 09:47:26 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/powerpc/include/asm arch/powerpc

Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree

Stephen Rothwell s...@canb.auug.org.au wrote: I just removed epapr_hcalls.h from the Kbuild file as I am not sure how it should be broken up. David, can you have a look at this, please? Files should be broken up along around __KERNEL__ conditionals. If there are no __KERNEL__ conditionals,

Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree

Tabi Timur-B04825 b04...@freescale.com wrote: What is include/uapi? Take a look at http://lwn.net/Articles/507794/ David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree

Alexander Graf ag...@suse.de wrote: Do I have to move them to their own header file or can I just #ifdef __KERNEL__ around the place where __ASSEMBLY__ starts to the end of the file? That depends on whether it happens before or after my disintegration script is run on the header. Ben has

Re: [PATCH 3/8] mm: use vm_unmapped_area() on frv architecture

Michel Lespinasse wal...@google.com wrote: Update the frv arch_get_unmapped_area function to make use of vm_unmapped_area() instead of implementing a brute force search. Signed-off-by: Michel Lespinasse wal...@google.com Acked-by: Rik van Riel r...@redhat.com Acked-by: David Howells dhowe

Re: [PATCH v5 01/45] percpu_rwlock: Introduce the global reader-writer lock backend

Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: We can use global rwlocks as shown below safely, without fear of deadlocks: Readers: CPU 0CPU 1 -- -- 1.spin_lock(random_lock);

Re: [PATCH 2.6.30-rc5] ehea: fix invalid pointer access

Hannes Hering hannes.her...@linux.vnet.ibm.com wrote: pref = skb_array[x]; - prefetchw(pref); - prefetchw(pref + EHEA_CACHE_LINE); + if (pref) { + prefetchw(pref); + prefetchw(pref + EHEA_CACHE_LINE); Ummm... Is prefetch() or prefetchw() faulting?

Re: Inline Assembly queries

kernel mailz kernelma...@googlemail.com wrote: asm(sync); Isn't gcc free to discard this as it has no dependencies, no indicated side effects, and isn't required to be kept? I think this should probably be: asm volatile(sync); David ___

Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()

as well add the argument everywhere. I added it to the pmd and pud variants for consistency. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Acked-by: David Howells dhowe...@redhat.com [MN10300 FRV] ___ Linuxppc-dev mailing list Linuxppc-dev

Re: spin_is_locked() broken for uniprocessor?

Thomas Gleixner t...@linutronix.de wrote: which implies to me that spin_is_locked() will always return false. Is this expected behavior. That's wrong. spin_is_locked should always return true on UP. Surely it's not that simple? Maybe spin_is_lock() should be undefined on UP. David

Re: [PATCH] documentation: Add disclaimer

Paul E. McKenney wrote: > Good point! Would you be willing to add a Signed-off-by so I > can take the combined change, assuming Peter and Will are good > with it? Sure! David ___ Linuxppc-dev mailing list

Re: [PATCH] documentation: Add disclaimer

Peter Zijlstra wrote: > +== > +DISCLAIMER > +== > + > +This document is not a specification; it is intentionally (for the sake of > +brevity) and unintentionally (due to being human) incomplete. This document > is > +meant as a guide to using the various

[no subject]

Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. Exported how? > +#ifdef __INT32_TYPE__ > +#undef __INT32_TYPE__ > +#define __INT32_TYPE__ int > +#endif > + > +#ifdef __UINT32_TYPE__ > +#undef __UINT32_TYPE__ > +#define

[no subject]

> -header-y += msr-index.h I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at least four years - and as such it's part of the UAPI. I don't think you can remove it unless you can guarantee there are no userspace users. David

[PATCH 07/14] spufs: Implement show_options

Implement the show_options superblock op for spufs as part of a bid to get rid of s_options and generic_show_options() to make it easier to implement a context-based mount where the mount options can be passed individually over a file descriptor. Signed-off-by: David Howells <dhowe...@redhat.

Re: [PATCH 0/2] Use ARRAY_SIZE to replace its implementation

> "Use ARRAY_SIZE to replace its implementation" Um, the subject line doesn't make sense. David

[RFC PATCH 7/8] vfs: Convert spufs to fs_context

Signed-off-by: David Howells cc: Jeremy Kerr cc: Arnd Bergmann cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/platforms/cell/spufs/inode.c | 207 - 1 file changed, 116 insertions(+), 91 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b

[RFC PATCH 0/8] Convert mount_single-using filesystems to fs_context

git/linux/kernel/git/dhowells/linux-fs.git/log/?h=mount-api-viro Thanks, David --- David Howells (8): vfs: Add a single-or-reconfig keying to vfs_get_super() vfs: Convert debugfs to fs_context vfs: Convert tracefs to fs_context vfs: Convert pstore to fs_context hypfs:

[RFC PATCH 16/68] vfs: Convert cxl to use the new mount API

-by: David Howells Acked-by: Andrew Donnellan Acked-by: Frederic Barrat cc: linuxppc-dev@lists.ozlabs.org --- drivers/misc/cxl/api.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c index 750470ef2049..395e9a88e6ba

[RFC PATCH 60/68] vfs: Convert spufs to use the new mount API

-off-by: David Howells cc: Jeremy Kerr cc: Arnd Bergmann cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/platforms/cell/spufs/inode.c | 207 - 1 file changed, 116 insertions(+), 91 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc

[RFC PATCH 00/68] VFS: Convert a bunch of filesystems to the new mount API

rts a slew of filesystems to use the mount API. (9) Fixes a bug in hypfs. The patches can be found here also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-viro David --- Andrew Price (1): gfs2: Convert gfs2 to fs_context Da

[PATCH 13/38] vfs: Convert cxl to fs_context

Signed-off-by: David Howells cc: Frederic Barrat cc: Andrew Donnellan cc: linuxppc-dev@lists.ozlabs.org --- drivers/misc/cxl/api.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c index 750470ef2049..395e9a88e6ba

[PATCH 00/38] VFS: Convert trivial filesystems and more

ere also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-viro David --- David Howells (38): vfs: Provide sb->s_iflags settings in fs_context struct vfs: Provide a mount_pseudo-replacement for fs_context vfs: Conve

Re: [PATCH 1/2] open: add close_range()

Al Viro wrote: > Umm... That's going to be very painful if you dup2() something to MAX_INT and > then run that; roughly 2G iterations of bouncing ->file_lock up and down, > without anything that would yield CPU in process. > > If anything, I would suggest something like > > fd =

Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP

Hillf Danton wrote: > - struct request_key_auth *rka = dereference_key_rcu(key); > + struct request_key_auth *rka; > + > + rcu_read_lock(); > + rka = dereference_key_rcu(key); This shouldn't help as the caller, proc_keys_show(), is holding the RCU read lock across the call. The

Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP

for a NULL pointer when describing such a key. Also make the read routine check for a NULL pointer to be on the safe side. Fixes: 04c567d9313e ("[PATCH] Keys: Fix race between two instantiators of a key") Reported-by: Sachin Sant Signed-off-by: David Howells

Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP

Hillf Danton wrote: > 1, callee has no pre defined duty to help caller in general; they should not > try to do anything, however, to help their callers in principle due to > limited info on their hands IMO. Ah, no. It's entirely reasonable for an API to specify that one of its methods will be

Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP

key") Reported-by: Sachin Sant Signed-off-by: David Howells Tested-by: Sachin Sant diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c index e73ec040e250..ecba39c93fd9 100644 --- a/security/keys/request_key_auth.c +++ b/security/keys/request_

Re: [PATCH v12 10/12] namei: aggressively check for nd->root escape on ".." resolution

Linus Torvalds wrote: > > Hinting to userspace to do a retry (with -EAGAIN as you mention in your > > other mail) wouldn't be a bad thing at all, though you'd almost > > certainly get quite a few spurious -EAGAINs -- &{mount,rename}_lock are > > global for the entire machine, after all. > > I'd

Re: [PATCH v1 1/2] PCI/AER: Use for_each_set_bit()

Andy Shevchenko wrote: > > but I confess to being a little ambivalent. It's > > arguably a little easier to read, > > I have another opinion here. Instead of parsing body of for-loop, the name of > the function tells you exactly what it's done. Besides the fact that reading > and parsing two

Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()

diting of the kfree_sensitive() kerneldoc and the > use of memzero_explicit() instead of memset(). > > Suggested-by: Joe Perches > Signed-off-by: Waiman Long Since this changes a lot of crypto stuff, does it make sense for it to go via the crypto tree? Acked-by: David Howells

Re: [PATCH 02/10] fs: don't allow splice read/write without explicit ops

Christoph Hellwig wrote: > > That said, for afs at least, the fix seems to be just this: > > And that is the correct fix, I was about to send it to you. Thanks. David

Re: [PATCH 02/10] fs: don't allow splice read/write without explicit ops

David Howells wrote: > > default_file_splice_write is the last piece of generic code that uses > > set_fs to make the uaccess routines operate on kernel pointers. It > > implements a "fallback loop" for splicing from files that do not actually > > provide a pro

Re: [PATCH 02/10] fs: don't allow splice read/write without explicit ops

Christoph Hellwig wrote: > default_file_splice_write is the last piece of generic code that uses > set_fs to make the uaccess routines operate on kernel pointers. It > implements a "fallback loop" for splicing from files that do not actually > provide a proper splice_read method. The usual

Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

Waiman Long wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() "memset()" is all lowercase. > is currently used for buffer clearing. However unlikely, there is still a >

Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

Jeff Layton wrote: > Correct. We'd lose some fidelity in currently stored timestamps, but as > Linus and Ted pointed out, anything below ~100ns granularity is > effectively just noise, as that's the floor overhead for calling into > the kernel. It's hard to argue that any application needs

Memory transaction instructions

Hi Linus, I'm not sure how relevant it is to the topic, but I seem to remember you having a go at implementing spinlocks with x86_64 memory transaction instructions a while back. Do you have any thoughts on whether these instructions are ever likely to become something we can use? I was looking

Re: Memory transaction instructions

Linus Torvalds wrote: > And for the kernel, where we don't have bad locking, and where we > actually use fine-grained locks that are _near_ the data that we are > locking (the lockref of the dcache is obviously one example of that, > but the skbuff queue you mention is almost certainly exactly

Re: Add fchmodat2() - or add a more general syscall?

Florian Weimer wrote: > > Rather than adding a fchmodat2() syscall, should we add a > > "set_file_attrs()" syscall that takes a mask and allows you to set a bunch > > of stuff all in one go? Basically, an interface to notify_change() in the > > kernel that would allow several stats to be set

Add fchmodat2() - or add a more general syscall?

Rather than adding a fchmodat2() syscall, should we add a "set_file_attrs()" syscall that takes a mask and allows you to set a bunch of stuff all in one go? Basically, an interface to notify_change() in the kernel that would allow several stats to be set atomically. This might be of particular