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
>
> bisection
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 real
[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 throug
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 yo
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?
___
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 yo
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 priva
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
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 mea
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-gf
-0400)
----
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 poin
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
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, if
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
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 dan
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
> > &
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 arselo
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..
On Thu, Jan 23, 2025 at 03:41:08PM +, Borah, Chaitanya Kumar wrote:
> Hello Al,
>
> Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
>
> This mail is regarding a regression we are seeing in our CI runs[1] on
> linux-next repository.
>
> Since the version next-2
The real fix follows:
[PATCH] Fix the missing initializations in __debugfs_file_get()
both method table pointers in debugfs_fsdata need to be initialized,
obviously...
Fixes: 41a0ecc0997c "debugfs: get rid of dynamically allocation proxy_ops"
Fucked-up-by: Al Viro
Signed-off-by: Al Vir
On Tue, Jan 28, 2025 at 04:00:58PM +, Borah, Chaitanya Kumar wrote:
> Unfortunately this change does not help us. I think it is the methods member
> that causes the problem. So the following change solves the problem for us.
>
>
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -102,
On Wed, Jan 29, 2025 at 08:53:37PM -, Patchwork wrote:
> == Series Details ==
>
> Series: Regression on linux-next (next-20250120) (rev2)
> URL : https://patchwork.freedesktop.org/series/143978/
> State : failure
>
> == Summary ==
>
> Error: patch
> https://patchwork.freedesktop.org/api/1
ously, and calculating the bitmap of present methods would also
go better if we start with initialized state.
Fixes: 41a0ecc0997c "debugfs: get rid of dynamically allocation proxy_ops"
Fucked-up-by: Al Viro
Signed-off-by: Al Viro
---
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
in
23 matches
Mail list logo
