Re: [PATCH 5/5] fs: Convert struct file::f_count to refcount_long_t

2024-05-02 Thread Al Viro
On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote: > But anyway, there needs to be a general "oops I hit 0"-aware form of > get_file(), and it seems like it should just be get_file() itself... ... which brings back the question of what's the sane damage mitigation for that. Adding

Re: [PATCH 5/5] fs: Convert struct file::f_count to refcount_long_t

2024-05-02 Thread Al Viro
On Thu, May 02, 2024 at 04:21:13PM -0700, Kees Cook wrote: > On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote: > > On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote: > > > > > As for semantics, what do you mean? Detecting dec-below-zero means we > > &

Re: [PATCH 5/5] fs: Convert struct file::f_count to refcount_long_t

2024-05-02 Thread Al Viro
On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote: > As for semantics, what do you mean? Detecting dec-below-zero means we > catch underflow, and detected inc-from-zero means we catch resurrection > attempts. In both cases we avoid double-free, but we have already lost > to a potential

Re: [PATCH 5/5] fs: Convert struct file::f_count to refcount_long_t

2024-05-02 Thread Al Viro
count_long_t. It is used on fairly hot paths. What's more, it's not at all obvious what the hell would right semantics be. NAKed-by: Al Viro

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()

2020-10-13 Thread Al Viro
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote: > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned > int size) > { > char *vto = kmap_atomic(to); > > memcpy(vto, vfrom, size); > kunmap_atomic(vto); > } > > in linux/highmem.h ? You

[Intel-gfx] [git pull] uaccess i915

2020-06-10 Thread Al Viro
) Al Viro (5): i915: switch query_{topology,engine}_info() to copy_to_user() i915: switch copy_perf_config_registers_or_number() to unsafe_put_user() i915 compat ioctl(): just use drm_ioctl_kernel() i915: alloc_oa_regs(): get rid of pointless

Re: [Intel-gfx] [PATCHES] uaccess i915

2020-05-29 Thread Al Viro
On Fri, May 29, 2020 at 08:06:14AM +0300, Jani Nikula wrote: > On Fri, 29 May 2020, Al Viro wrote: > > Low-hanging fruit in i915 uaccess-related stuff. > > There's some subtler stuff remaining after that; these > > are the simple ones. > > Please Cc: intel-gfx@lis

Re: [Intel-gfx] [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()

2020-04-20 Thread Al Viro
[rmk Cc'd] On Fri, Apr 03, 2020 at 09:52:05PM +0100, Al Viro wrote: > I can do a 5.7-rc1-based branch with that; depending upon what we end > up doing for arm and s390 we can always change the calling conventions > come next cycle ;-/ > > My impressions after digging through arm

Re: [Intel-gfx] [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()

2020-04-03 Thread Al Viro
On Fri, Apr 03, 2020 at 11:01:10AM -0700, Linus Torvalds wrote: > On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy > wrote: > > > > Now we have user_read_access_begin() and user_write_access_begin() > > in addition to user_access_begin(). > > I realize Al asked for this, but I don't think it

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

2020-02-28 Thread Al Viro
On Fri, Feb 28, 2020 at 07:04:41PM +0100, Peter Zijlstra wrote: > On Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote: > > > And why not mark gen8_canonical_addr() __always_inline? > > > > Right, marking those two functions as __always_inline is the other > > option. The problem is,

Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()

2020-02-27 Thread Al Viro
On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote: > With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports: > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with > UACCESS enabled > > This means

Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API

2019-08-07 Thread Al Viro
On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote: > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote: > > Though personally I'm averse to managing "f"objects through > > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works > > on the virtual address of

Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API

2019-08-07 Thread Al Viro
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote: > that mapping must have been decided previously). In Google we do use > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis - > one day I'll get to upstreaming those. That'd be nice - we could kill the i915 wierd

Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API

2019-08-05 Thread Al Viro
On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote: > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote: > > tmpfs does not set ->remount_fs() anymore and its users need > > to be converted to new mount API. > > Could you explain why the devil do

Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API

2019-08-05 Thread Al Viro
On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote: > tmpfs does not set ->remount_fs() anymore and its users need > to be converted to new mount API. Could you explain why the devil do you bother with remount at all? Why not pass the right options when mounting the damn thing?

Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API

2019-08-05 Thread Al Viro
On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote: > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote: > > tmpfs does not set ->remount_fs() anymore and its users need > > to be converted to new mount API. > > Could you explain why the devil do

Re: [Intel-gfx] INFO: rcu detected stall in sys_sendfile64 (2)

2019-03-11 Thread Al Viro
On Mon, Mar 11, 2019 at 08:59:00PM -0700, syzbot wrote: > syzbot has bisected this bug to: > > commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb > Author: Chris Wilson > Date: Thu Feb 8 10:54:48 2018 + > > drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early > >

Re: [Intel-gfx] [PATCH] x86, vm86: fix VM86 syscalls: use asmlinkage calling convention

2013-03-28 Thread Al Viro
On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote: Hi Al, Hans de Bruin found a regression due to one of your changes. I asked him to test a fix and he reported back that it worked. (Thanks!) Can you see if you agree with the fix? Patch is attached due to webmail...