On Thu, Aug 18, 2016 at 11:11:09PM -0700, Vineet Gupta wrote:
> On 08/17/2016 08:00 PM, Al Viro wrote:
> Just curious - why is that. The typical usage paradigm is check for return
> value
> and if 0 only then proceed to use the actual value.
>
> Also for discussion sake, wi
On Tue, Jan 14, 2020 at 01:22:07PM -0800, Linus Torvalds wrote:
> The fact is, copying a string from user space is *very* different from
> copying a fixed number of bytes, and that whole dance with
>
> max_addr = user_addr_max();
>
> is absolutely required and necessary.
>
> You complet
On Wed, Jan 15, 2020 at 10:08:31AM +0100, Arnd Bergmann wrote:
> > I would suggest that anybody who uses asm-generic/uaccess.h needs to
> > simply use the generic library version.
>
> Or possibly just everybody altogether: the remaining architectures that
> have a custom implementation don't seem
On Thu, Apr 30, 2020 at 01:38:40PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> Every arch has the same code to ensure atomic operations and a check for
> !HIGHMEM page.
>
> Remove the duplicate code by defining a core kmap_atomic() which only
> calls the arch specific kmap_atomic_hig
On Thu, Apr 30, 2020 at 01:38:43PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> To support kmap_atomic_prot() on all architectures each arch must
> support protections passed in to them.
>
> Change csky, mips, nds32 and xtensa to use their global kmap_prot value
> rather than a hard c
On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote:
> -static inline void *kmap_atomic(struct page *page)
> +static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
> {
> preempt_disable();
> pagefault_disable();
> if (!PageHighMem(page))
>
On Fri, May 01, 2020 at 03:37:34AM +0100, Al Viro wrote:
> On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote:
>
> > -static inline void *kmap_atomic(struct page *page)
> > +static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
> > {
On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap infrastructure has been copied almost verbatim to every architecture.
> This series consolidates obvious duplicated code by defining core functions
> which call into the architectures only when nee
On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote:
> Grepping for 'asm/highmem.h' and investigations don't reveal any issues...
> But
> you do have me worried. That said 0-day has been crunching on multiple
> versions of this series without issues such as this (save the mips issue
> abo
On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote:
> > || * arm: much, much worse. We have several files that pull
> > linux/highmem.h:
> > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
> > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c,
> >
On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > enables when vaddr is not in the fixmap.
> >
> > Fixes: b
On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
> On 5/21/20 10:27 AM, Al Viro wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> >> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> >>> From: Ira Weiny
On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
> > On 5/21/20 10:27 AM, Al Viro wrote:
> > > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > >> On Mon, May 18, 20
On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
> Mainline, with:
>
> qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
> -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
>
On Fri, May 22, 2020 at 02:29:50AM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
>
> > Mainline, with:
> >
> > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> > -snapshot -drive file=
On Thu, Dec 31, 2020 at 08:29:14PM -0800, Randy Dunlap wrote:
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in (beside copy_page()) and
> add to fs/dax.c to fix the build error.
>
> ../fs/dax.c: In function '
On Mon, Feb 14, 2022 at 05:34:45PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/csky/kernel/signal.c b/arch/csky/kernel/signal.c
> index c7b763d2f526..8867ddf3e6c7 100644
> --- a/arch/csky/kernel/signal.c
> +++ b/arch/csky/kernel/signal.c
> @@ -136,7 +136,7 @@ static inline void __user *get_sig
On Mon, Feb 14, 2022 at 12:01:05PM -0800, Linus Torvalds wrote:
> On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote:
> >
> > As Al pointed out, they turned out to be necessary on sparc64, but the only
> > definitions are on sparc64 and x86, so it's possible that they serve a
> > similar
> > pu
On Mon, Feb 14, 2022 at 05:34:43PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> All architectures that don't provide __{get,put}_kernel_nofault() yet
> can implement this on top of __{get,put}_user.
>
> Add a generic version that lets everything use the normal
> copy_{from,to}_kernel_no
On Mon, Feb 14, 2022 at 05:34:47PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> While most m68k platforms use separate address spaces for user
> and kernel space, at least coldfire does not, and the other
> ones have a TASK_SIZE that is less than the entire 4GB address
> range.
>
> Usin
On Mon, Feb 14, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote:
> -/*
> - * Sparc64 is segmented, though more like the M68K than the I386.
> - * We use the secondary ASI to address user memory, which references a
> - * completely different VM map, thus there is zero chance of the user
> - * doing s
On Mon, Feb 14, 2022 at 08:17:07PM +, Al Viro wrote:
> On Mon, Feb 14, 2022 at 12:01:05PM -0800, Linus Torvalds wrote:
> > On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote:
> > >
> > > As Al pointed out, they turned out to be necessary on sparc64, but the
>
On Mon, Feb 14, 2022 at 05:34:52PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
> index b5835325d44b..2f4a1b1ef387 100644
> --- a/arch/parisc/include/asm/futex.h
> +++ b/arch/parisc/include/asm/futex.h
> @@ -99,7 +99,7 @@ futex_atomic_
On Tue, Feb 15, 2022 at 07:29:42AM +0100, Christoph Hellwig wrote:
> On Tue, Feb 15, 2022 at 12:37:41AM +0000, Al Viro wrote:
> > Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES
> > (and trim the comment down to "coldfire and 68000 will pick generic
&
On Thu, Feb 17, 2022 at 07:20:11AM +, Christophe Leroy wrote:
> And we have also
> user_access_begin()/user_read_access_begin()/user_write_access_begin()
> which call access_ok() then do the real work. Could be made generic with
> call to some arch specific __user_access_begin() and friends
On Thu, Feb 17, 2022 at 08:49:59AM +0100, Arnd Bergmann wrote:
> Same here: architectures can already provide a __put_user_fn()
> and __get_user_fn(), to get the generic versions of the interface,
> but few architectures use that. You can actually get all the interfaces
> by just providing raw_cop
On Tue, Jan 10, 2023 at 07:08:33PM +0100, Christophe JAILLET wrote:
> Le 10/01/2023 à 08:19, Vineet Gupta a écrit :
> >
> > On 1/8/23 11:04, Christophe JAILLET wrote:
> > > In an attempt to simplify some includes in , it
> > > appeared, when compiling fs/ecryptfs/dentry.c, that
> > >
> > > was re
27 matches
Mail list logo
