Michel Lespinasse 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
> Acked-by: Rik van Riel
Acked-by
Srivatsa S. Bhat wrote:
> We can use global rwlocks as shown below safely, without fear of deadlocks:
>
> Readers:
>
> CPU 0CPU 1
> -- --
>
> 1.spin_lock(&random_lock); read_lock(&my_rwlock)
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
cc: Li Yang
cc: Felipe Balbi
cc: Greg Kroah-Hartman
cc: linux-...@vger.kernel.org
cc: linuxppc-dev@lists.ozlabs.org
---
drivers/usb/g
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
cc: linuxppc-dev@lists.ozlabs.org
cc: linux-me...@vger.kernel.org
cc: net...@vger.kernel.org
cc: linux-wirel...@vger.kernel.org
cc
ltiplex what the update file read method does 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:
doesn't have a destructor).
Signed-off-by: David Howells
cc: Benjamin Herrenschmidt
cc: Paul Mackerras
cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/pseries/scanlog.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/arch/power
Brian Norris wrote:
> I'm looking to use roundup_pow_of_two() (actually, order_base_2())
> from , 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 explicitly designed for 32-bit or 64-bit
> co
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 memory barriers provided
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
Linuxppc-dev@lists.ozlabs.org
https://lists.o
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
be found here 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
org/cgit/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
hy
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
-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
-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
8) Converts 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_c
> followed by some editing 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
> "Use ARRAY_SIZE to replace its implementation"
Um, the subject line doesn't make sense.
David
ells/linux-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
tegrate arch/powerpc/include/asm (2012-10-09 09:47:26
+0100)
UAPI Disintegration 2012-10-09
--------
David Howells (1):
UAPI: (Scripted) Disintegrate arch/powerpc/includ
Stephen Rothwell 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, it is assumed that th
Tabi Timur-B04825 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
Alexander Graf 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 pulled my powe
leads to commit 9ffc93f203c18a70623f21950f1dd473c9ec48cd
>
> "Remove all #inclusions of asm/system.h"
>
> Add the debug header which contains powerpc_debugfs_root.
>
> Cc: David Howells
> Signed-off-by: Paul Gortmaker
Acked-by: David Howells
__
Thomas Gleixner 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
_
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
---
drivers/net/ehea/ehea_main.c | 13
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
---
drivers/net/ehea/ehea_main.c | 13
Julia Lawall 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
ErrorDocument t
David Howells 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
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
want to use this macro.
>
> Reported-by: David S. Miller
> Signed-off-by: Sven Eckelmann
Acked-by: David Howells [MN10300 and FRV]
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Peter Zijlstra 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 nommu?
>
> ---
>
Peter Zijlstra wrote:
> Subject: mm: Fix fixup_user_fault() for MMU=n
>
> In commit 2efaca927 ("mm/futex: fix futex writes on archs with SW
> tracking of dirty & young") we forgot about MMU=n. This patch fixes
> that.
>
> Signed-off-by: Peter
CENSE("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
---
arch/powerpc/lib/string.S |4 +++-
1 files changed, 3 insertions
K.Prasad 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 in which they ar
Steve Best 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])) - KERNELBASE;
which seems
Josh Boyer 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
https://lists.ozlabs.org/listinfo/linuxppc-dev
Michael Neuling wrote:
> No logic changes, only spelling.
>
> Signed-off-by: Michael Neuling
Acked-by: David Howells
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Ravi Gupta 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 access to page-aligned dat
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 --
arch/powerpc
Hannes Hering 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?
David
___
Hannes Hering wrote:
> this is an ehea driver problem, which is occuring when the receive queue runs
> empty. The faulting code is more specifically the following line:
>
> pref = (skb_array[x]->data);
In that case, you might want to move the prefetchw() calls in the following:
kernel mailz 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
___
Linuxppc-dev mailing list
s and
> almost everybody implemets these as macros, so we may as well add the
> argument everywhere. I added it to the pmd and pud variants for consistency.
>
> Signed-off-by: Benjamin Herrenschmidt
Acked-by: David Howells [MN10300 & FRV]
___
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
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 c
y checking 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
ators of a
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/key
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
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 li
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 that
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 in
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 ato
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 file
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
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
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
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 th
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 probabil
ings that we've
tried to make sure specifically aren't declared.
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 i
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 &
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
ures:
> ...
> - frv
> ...
> - 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
gt; Also PERCPU macro is used 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
at (3), has a different ROM 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
ic version instead.
>
> 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".
>
>
her IORESOURCE_IO nor 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]>
__
her IORESOURCE_IO nor 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]>
__
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
Sergey Temerkhanov <[EMAIL PROTECTED]> wrote:
> And handle_level_irq() which is currently used as high-level IRQ handler for
> Xilinx INTC only tries to acknowledge IRQ before ISR call. So that the IRQ
> remains asserted in INTC and after the call to desc->chip->unmask() causes
> spurious attempt
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), "=
se RCU directly rather than a convenient wrapper; these will be
addressed by later patches.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
Reviewed-by: James Morris <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc:
cking 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]>
---
a
Vitaly Mayatskikh <[EMAIL PROTECTED]> wrote:
> + if (!logging_enabled) {
> + spin_unlock_irqrestore(&rtasd_log_lock, s);
> + error = -ENODATA;
> + goto out;
> + } else
> + nvram_clear_error_log(
-dec generic algorithm, though
you have to take that with a pinch of salt as I don't have SMP hardware for
it.
Acked-by: David Howells <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 yo
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 mak
of RAM 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
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 differen
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
> non-ze
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 = *start_f
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
cc: Jeremy Kerr
cc
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 __UINT32_TYPE__ unsigned int
> -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
84 matches
Mail list logo
