Morton
Signed-off-by: Cyrill Gorcunov
---
kernel/sys.c | 70 ---
1 file changed, 38 insertions(+), 32 deletions(-)
Index: linux-tip.git/kernel/sys.c
===
--- linux-tip.git.orig/
On Sun, Mar 21, 2021 at 11:36:42PM +0300, Cyrill Gorcunov wrote:
> Alexey reported that current PR_SET_MM_AUXV (and PR_SET_MM_MAP) overwrite
> too many entries on non 64bit kernels. This is because auxv is defined
> as an array of longs and in result access to AT_VECTOR_SIZE
: Andrey Vagin
CC: Dmitry Safonov <0x7f454...@gmail.com>
CC: Andrew Morton
Signed-off-by: Cyrill Gorcunov
---
Take a look please, once time permit. The issue on its own
should not be that critical but better to fix it. I tested
it manually via trivial test but I think it is not enough
On Tue, Mar 16, 2021 at 09:50:35PM +0300, Alexey Dobriyan wrote:
> > >
> > > There is another (non-security) one. Compat 32-bit process will report
> > > 2 longs too many:
> >
> > Good catch! Alexey, should I address it? Or you have fixed it already?
>
> I didn't and I don't know how frankly.
>
On Mon, Mar 15, 2021 at 02:19:12PM +0100, Oleg Nesterov wrote:
> > >
> > > And why task_lock(current) ? What does it try to protect?
> >
> > As far as I remember this was related to reading from procfs
> > at time the patch was written for first time. Looks like this
> > not relevant anymore and
On Mon, Mar 15, 2021 at 01:08:03PM +0100, Oleg Nesterov wrote:
> On 03/14, Alexey Dobriyan wrote:
> >
> > prctl(PR_SET_MM, PR_SET_MM_AUXV, addr, 1);
> >
> > will copy 1 byte from userspace to (quite big) on-stack array
> > and then stash everything to mm->saved_auxv.
>
> I too don't
On Mon, Mar 15, 2021 at 09:00:00AM +0300, Alexey Dobriyan wrote:
> On Sun, Mar 14, 2021 at 02:40:05PM -0700, Linus Torvalds wrote:
> > [mm->saved_auxv]
> >
> > That's a separate issue, and I can't find it in myself to care (and
> > nobody has ever complained), but I thought I'd mention it.
>
>
On Sun, Mar 14, 2021 at 02:40:05PM -0700, Linus Torvalds wrote:
> Applied directly, since I'm just about to tag rc3 and was just looking
> that there were no last-minute pull requests.
>
> Andrew, no need to pick it up into your queue.
>
> Side note: I think we should return -EINVAL more
On Sun, Mar 14, 2021 at 11:51:14PM +0300, Alexey Dobriyan wrote:
> prctl(PR_SET_MM, PR_SET_MM_AUXV, addr, 1);
>
> will copy 1 byte from userspace to (quite big) on-stack array
> and then stash everything to mm->saved_auxv.
> AT_NULL terminator will be inserted at the very end.
>
>
"J. Bruce Fields"
> Cc: Alexander Viro
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Cyrill Gorcunov
> Cc: Andrei Vagin
> Signed-off-by: Pavel Tikhomirov
I can't imagine a scenario where we could break some backward
compatibility with this change, so
Reviewed-by: Cyrill Gorcunov
mabuf) point to the same struct file. Since they depend on it for
> core functionality, lift SYS_kcmp out of the non-default
> CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
>
...
Reviewed-by: Cyrill Gorcunov
On Wed, Feb 03, 2021 at 02:55:34PM -0800, Yu-cheng Yu wrote:
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 602e3a52884d..59623dcd92bb 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -661,6 +661,9 @@ static void show_smap_vma_flags(struct seq_file *m,
>
On Thu, Feb 04, 2021 at 12:35:42AM +0300, Pavel Tikhomirov wrote:
>
> AFAICS if pid is held only by 1) fowner refcount and by 2) single process
> (without threads, group and session for simplicity), on process exit we go
> through:
>
> do_exit
> exit_notify
> release_task
>
On Wed, Feb 03, 2021 at 03:41:56PM +0300, Pavel Tikhomirov wrote:
> Currently there is no way to differentiate the file with alive owner
> from the file with dead owner but pid of the owner reused. That's why
> CRIU can't actually know if it needs to restore file owner or not,
> because if it
of expanding VMAs via new values
shipped with prctl call.
Reported-by: Keno Fischer
Signed-off-by: Cyrill Gorcunov
CC: Andrew Morton
CC: Dmitry Safonov <0x7f454...@gmail.com>
CC: Andrey Vagin
CC: Kirill Tkhai
CC: Eric W. Biederman
---
Guys, take a look please once time permit. Hopefully I
On Thu, Dec 17, 2020 at 10:42:02AM +0300, Cyrill Gorcunov wrote:
> On Wed, Dec 16, 2020 at 08:29:30PM -0500, Keno Fischer wrote:
> > Hi all,
> >
> > The code in prctl(PR_SET_MM, ...) performs a number of sanity checks,
> > among them
> >
> > ```
>
On Wed, Dec 16, 2020 at 08:29:30PM -0500, Keno Fischer wrote:
> Hi all,
>
> The code in prctl(PR_SET_MM, ...) performs a number of sanity checks,
> among them
>
> ```
> /*
> * @brk should be after @end_data in traditional maps.
> */
> if (prctl_map->start_brk <= prctl_map->end_data ||
>
use the helper to make a simpler implementation of get_file_raw_ptr.
>
> Signed-off-by: "Eric W. Biederman"
Acked-by: Cyrill Gorcunov
Since I wrote this kcmp code in first place. Thanks Eric!
On Sun, Nov 22, 2020 at 07:00:20AM -0600, Eric W. Biederman wrote:
> Cyrill Gorcunov writes:
...
> That is present in files_lookup_fd_rcu, so this code should
> be good from the warning side.
Indeed, thanks!
On Fri, Nov 20, 2020 at 05:14:28PM -0600, Eric W. Biederman wrote:
>
> diff --git a/fs/file.c b/fs/file.c
> index 5861c4f89419..6448523ca29e 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -865,6 +865,21 @@ struct file *fget_task(struct task_struct *task,
> unsigned int fd)
> return file;
On Tue, Oct 27, 2020 at 08:22:11PM +0300, Kirill Tkhai wrote:
> 1)Before my commit there also were different checks
>
> !capable(CAP_SYS_RESOURCE))
> and
> uid_eq(cred->uid, make_kuid(ns, 0)) && gid_eq(cred->gid, make_kgid(ns,
> 0))
>
> so it is not the initial reason. The commit
On Tue, Oct 27, 2020 at 01:11:40PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Nicolas, Cyrill, and others,
>
> @Nicolas, your commit ebd6de6812387a changed the capability
> requirements for the prctl_set_mm_exe_file() operation from
>
> ns_capable(CAP_SYS_ADMIN)
>
> to
>
>
On Mon, Oct 12, 2020 at 08:38:27AM -0700, Yu-cheng Yu wrote:
...
> /*
> * x86-64 Task Priority Register, CR8
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index 038e19c0019e..705fd9b94e31 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++
On Mon, Oct 12, 2020 at 08:45:24AM -0700, Yu-cheng Yu wrote:
...
> + the application support it. When this feature is enabled,
> + legacy non-IBT applications continue to work, but without
> + IBT protection.
> + Support for this feature is only known to be present on
> +
On Mon, Aug 17, 2020 at 05:04:17PM -0500, Eric W. Biederman wrote:
> As a companion to fget_task and fcheck_task implement fnext_task that
> will return the struct file for the first file descriptor show number
> is equal or greater than the fd argument value, or NULL if there is
> no such struct
result in exec unnecessarily unsharing files_struct and breaking posix
> locks, and it can result in fget_light having to fallback to fget reducing
> performance.
>
> Suggested-by: Oleg Nesterov
> Signed-off-by: "Eric W. Biederman"
Reviewed-by: Cyrill Gorcunov
I really like this simplification!
such extension is that when you read get_xsaves_size
you'll notice the dependency on dynamic features immediaely.
Though I'm fine with current patch as well, up to you. Thanks for the patch!
Reviewed-by: Cyrill Gorcunov
looks OK to me, fwiw
Reviewed-by: Cyrill Gorcunov
On Fri, Jul 10, 2020 at 11:05:11AM +0200, Rasmus Villemoes wrote:
> >> I deliberately drop the ifdef in the eventpoll.h header rather than
> >> replace with KCMP_SYSCALL; it's harmless to declare a function that
> >> isn't defined anywhere.
> >
> > Could you please point why setting #fidef
an
> replace with KCMP_SYSCALL; it's harmless to declare a function that
> isn't defined anywhere.
Could you please point why setting #fidef KCMP_SYSCALL in eventpoll.h
is not suitable? Still the overall idea is fine for me, thanks!
Reviewed-by: Cyrill Gorcunov
On Tue, Jul 07, 2020 at 05:45:04PM +0200, Christian Brauner wrote:
...
>
> Ok, so the original patch proposal was presented in [4] in 2014. The
> final version of that patch added the PR_SET_MM_MAP we know today. The
> initial version presented in [4] did not require _any_ privilege.
>
True. I
On Mon, Jun 22, 2020 at 03:11:07PM -0400, Liang, Kan wrote:
> >
> > The goto and "return" statement before the "rollback" label
> > looks pretty ugly. I'm sorry I didn't follow the series
> > in details so if you plan to add more handlers at "rollback"
> > then sure.
> >
>
> There were several
On Fri, Jun 19, 2020 at 07:04:09AM -0700, kan.li...@linux.intel.com wrote:
...
> +static void intel_pmu_arch_lbr_read_xsave(struct cpu_hw_events *cpuc)
> +{
> + struct x86_perf_task_context_arch_lbr_xsave *xsave = cpuc->lbr_xsave;
> + struct arch_lbr_entry *lbr;
> + int i;
> +
> +
On Tue, Jun 09, 2020 at 08:09:49PM +, Nicolas Viennot wrote:
> >> proc_map_files_get_link(struct dentry *dentry,
> >>struct inode *inode,
> >>struct delayed_call *done)
> >> {
> >> - if (!capable(CAP_SYS_ADMIN))
> >> + if (!(capable(CAP_SYS_ADMIN) ||
On Wed, Jun 03, 2020 at 06:23:26PM +0200, Adrian Reber wrote:
> This patch introduces CAP_CHECKPOINT_RESTORE, a new capability facilitating
> checkpoint/restore for non-root users.
>
> Over the last years, The CRIU (Checkpoint/Restore In Userspace) team has been
> asked numerous times if it is
On Wed, Jun 03, 2020 at 06:23:26PM +0200, Adrian Reber wrote:
...
>
> /*
> - * Only allow CAP_SYS_ADMIN to follow the links, due to concerns about how
> the
> - * symlinks may be used to bypass permissions on ancestor directories in the
> - * path to the file in question.
> + * Only allow
On Wed, Oct 23, 2019 at 11:31:40AM -0700, Matthew Wilcox wrote:
> On Wed, Oct 23, 2019 at 08:05:49PM +0200, Thomas Gleixner wrote:
> > Prevent this by checking the validity of the cea_exception_stack base
> > address and bailing out if it is zero.
>
> Could also initialise cea_exception_stack to
On Wed, Oct 23, 2019 at 03:47:57PM +0200, Thomas Gleixner wrote:
>
> So the fix is trivial.
Works like a charm.
Tested-by: Cyrill Gorcunov
On Wed, Oct 23, 2019 at 03:47:57PM +0200, Thomas Gleixner wrote:
>
> And you are right this happens because cea_exception_stacks is not yet
> initialized which makes begin = 0 and therefore point into nirvana.
>
> So the fix is trivial.
Great! Thanks a lot for sych detailed analysis! I'll test
On Wed, Oct 23, 2019 at 03:38:40PM +0200, Thomas Gleixner wrote:
> > >
> > > [0,2,4,5,6,8,10,12] are guard pages so 0 is not that crappy at all
> >
> > Wait, Thomas, I might be wrong, but per-cpu is initialized to the pointer,
> > the memory for this estack_pages has not yet been allocated, no?
On Wed, Oct 23, 2019 at 03:21:05PM +0200, Thomas Gleixner wrote:
> On Tue, 22 Oct 2019, Cyrill Gorcunov wrote:
> > On Tue, Oct 22, 2019 at 05:23:25PM +0300, Cyrill Gorcunov wrote:
> > >
> > > I presume the kmemleak tries to save stack trace too early when
> >
On Tue, Oct 22, 2019 at 09:11:04PM -0700, Andy Lutomirski wrote:
> Trying again. It looks like I used the wrong address for Pavel.
Thanks for CC Andy! I must confess I didn't dive into userfaultfd engine
personally but let me CC more people involved from criu side. (overquoting
left untouched
On Tue, Oct 22, 2019 at 05:23:25PM +0300, Cyrill Gorcunov wrote:
>
> I presume the kmemleak tries to save stack trace too early when estack_pages
> are not
> yet filled.
Indeed, at this stage of boot the percpu_setup_exception_stacks has not been
called
yet and estack_pages
On Sat, Oct 19, 2019 at 02:44:21PM +0300, Cyrill Gorcunov wrote:
...
>
> I nailed it down to the following kmemleak code
>
> create_object
> ...
> object->trace_len = __save_stack_trace(object->trace);
>
> if I drop this line out it boots fine. Just w
Hi! I'm not sure if I've CC'ed proper persons, so please sorry if I did.
Anyway, today's -tip (07b4dbf1d830) refused to boot
[0.024793] No NUMA configuration found
[0.025406] Faking a node at [mem 0x-0x7ffdefff]
[0.026462] NODE_DATA(0) allocated [mem
On Fri, Sep 20, 2019 at 05:11:00PM +0300, Kirill Tkhai wrote:
>
> The current scheme is following. We allocate shrinker_map in css_online,
> while normal freeing happens in css_free. The NULLifying of pointer is needed
> in case of "abnormal freeing", when memcg_free_shrinker_maps() is called
>
On Fri, Sep 20, 2019 at 04:21:14PM +0300, Kirill A. Shutemov wrote:
> On Fri, Sep 20, 2019 at 03:29:07PM +0300, Cyrill Gorcunov wrote:
> > Currently there is a small gap between fetching pointer, calling
> > kvfree and assign its value to nil. In current callgraph it is
> >
eliminate the gap at all.
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Kirill Tkhai
Signed-off-by: Cyrill Gorcunov
---
mm/memcontrol.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-tip.git/mm/memcontrol.c
On Mon, Sep 09, 2019 at 11:23:35AM +0100, Dmitry Safonov wrote:
> Shift on s64 is faster than division, use it instead.
>
> As the result of the patch there is a hardly user-visible effect:
> poll(), select(), etc syscalls will be a bit more precise on ~2.3%
> than before because 1000 != 1024 :)
and prevent any possible overrun errors when printing cpu name.
For this sake just increase the buffer up to be able to keep any level.
CC: Ingo Molnar
CC: Thomas Gleixner
Signed-off-by: Cyrill Gorcunov
---
arch/x86/boot/cpu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-tip.git
On Mon, Sep 09, 2019 at 12:50:27PM +0100, Dmitry Safonov wrote:
> Hi Cyrill,
>
> On Mon, 9 Sep 2019 at 12:18, Cyrill Gorcunov wrote:
> > Compiler precompute constants so it doesn't do division here.
> > But I didn't read the series yet so I might be missing
> > someth
On Mon, Sep 09, 2019 at 11:23:35AM +0100, Dmitry Safonov wrote:
> Shift on s64 is faster than division, use it instead.
>
> As the result of the patch there is a hardly user-visible effect:
> poll(), select(), etc syscalls will be a bit more precise on ~2.3%
> than before because 1000 != 1024 :)
mer_slack" field in the task
> struct")
> Signed-off-by: Yang Xu
> Cc: Cyrill Gorcunov
Acked-by: Cyrill Gorcunov
On Tue, Jul 23, 2019 at 04:11:09PM +0800, Yang Xu wrote:
> > 2) according to man page passing negative value should be acceptable,
> > though it never worked as expected. I've been grepping "git log"
> > for this file and the former API is coming from
> >
> > commit
On Tue, Jul 23, 2019 at 11:30:53AM +0800, Yang Xu wrote:
> arg2 will never < 0, for its type is 'unsigned long'. So negative
> judgment is meaningless.
>
> Signed-off-by: Yang Xu
> ---
> kernel/sys.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sys.c
> It seems ->d_revalidate() could return any error (except ECHILD) to
> > abort validation and pass error as result of lookup sequence.
> >
> > Signed-off-by: Konstantin Khlebnikov
> > Reviewed-by: Roman Gushchin
> > Reviewed-by: Cyrill Gorcunov
> >
On Wed, Jun 12, 2019 at 10:51:59AM -0700, Matthew Wilcox wrote:
> On Wed, Jun 12, 2019 at 07:29:15PM +0200, Michal Koutný wrote:
> > On Wed, Jun 12, 2019 at 10:00:34AM -0700, Matthew Wilcox
> > wrote:
> > > On Wed, Jun 12, 2019 at 04:28:11PM +0200, Michal Koutný wrote:
> > > > - /* N.B.
es to mm_struct in exec path are protected by mmap_sem, so
> conservatively, protect also this one. Besides that, explain why we omit
> mm_struct.arg_lock in the exec(2) path.
>
> Cc: Cyrill Gorcunov
> Signed-off-by: Michal Koutný
> ---
>
> When I was attempting to reduce usage
at I dont agree
with. But again, I'm not a maintainer and might be wrong.
>
> On Wed, May 29, 2019 at 8:18 PM Cyrill Gorcunov wrote:
> >
> > On Wed, May 29, 2019 at 10:39:52AM +0800, Dianzhang Chen wrote:
> > > Hi,
> > >
> > > Although when detect it
On Wed, May 29, 2019 at 10:39:52AM +0800, Dianzhang Chen wrote:
> Hi,
>
> Although when detect it is misprediction and drop the execution, but
> it can not drop all the effects of speculative execution, like the
> cache state. During the speculative execution, the:
>
>
> rlim =
On Tue, May 28, 2019 at 10:37:10AM +0800, Dianzhang Chen wrote:
> Hi,
> Because when i reply your email，i always get 'Message rejected' from
> gmail(get this rejection from all the recipients). I still don't know
> how to deal with it, so i reply your email here:
Hi! This is weird. Next time
On Mon, May 27, 2019 at 03:23:08PM +0800, Dianzhang Chen wrote:
> The `resource` in do_prlimit() is controlled by userspace via syscall:
> setrlimit(defined in kernel/sys.c), hence leading to a potential exploitation
> of the Spectre variant 1 vulnerability.
> The relevant code in do_prlimit()
enario where might_sleep may trigger a warning, and didn't
find one, so should be safe).
Reviewed-by: Cyrill Gorcunov
On Thu, May 02, 2019 at 05:46:08PM -0400, Joel Savitz wrote:
> > Won't be possible to use put_user here? Something like
> >
> > static int prctl_get_tasksize(unsigned long __user *uaddr)
> > {
> > return put_user(TASK_SIZE, uaddr) ? -EFAULT : 0;
> > }
>
> What would be the benefit of
On Thu, May 02, 2019 at 05:01:38PM -0400, Waiman Long wrote:
>
> What did you change in v2 versus v1?
Seems unsigned long long has been changed to unsigned long.
On Thu, May 02, 2019 at 04:52:21PM -0400, Joel Savitz wrote:
>
> +static int prctl_get_tasksize(void __user * uaddr)
> +{
> + unsigned long task_size = TASK_SIZE;
> + return copy_to_user(uaddr, _size, sizeof(unsigned long))
> + ? -EFAULT : 0;
> +}
Won't be possible
t of
> the function and make the function perform purely arithmetic checks.
>
> This patch should not change any behavior, it is mere refactoring for
> following patch.
>
> v1, v2: ---
> v3: Remove unused mm variable from validate_prctl_map_addr
>
> CC: Kirill Tkhai
> CC
t arg_lock held
> v3: squashed get_cmdline arg_lock patch
>
> Fixes: 88aa7cc688d4 ("mm: introduce arg_lock to protect arg_start|end and
> env_start|end in mm_struct")
> Cc: Yang Shi
> Cc: Mateusz Guzik
> CC: Cyrill Gorcunov
> Co-developed-by: Laurent Dufour
> Signed-off-by: Laurent Dufour
> Signed-off-by: Michal Koutný
Reviewed-by: Cyrill Gorcunov
On Tue, Apr 30, 2019 at 12:56:10PM +0200, Michal Koutný wrote:
> On Tue, Apr 30, 2019 at 01:45:17PM +0300, Cyrill Gorcunov
> wrote:
> > It setups these parameters unconditionally. I need to revisit
> > this moment. Technically (if only I'm not missing something
> > obvio
On Tue, Apr 30, 2019 at 12:53:51PM +0300, Kirill Tkhai wrote:
> >
> > Well, strictly speaking we probably should but you know setup of
> > the @arg_start by kernel's elf loader doesn't cause any side
> > effects as far as I can tell (its been working this lockless
> > way for years, mmap_sem is
On Tue, Apr 30, 2019 at 12:09:57PM +0300, Kirill Tkhai wrote:
>
> This looks OK for me.
>
> But speaking about existing code it's a secret for me, why we ignore arg_lock
> in binfmt code, e.g. in load_elf_binary().
Well, strictly speaking we probably should but you know setup of
the @arg_start
On Tue, Apr 30, 2019 at 11:55:45AM +0300, Kirill Tkhai wrote:
> > - up_write(>mmap_sem);
> > + spin_unlock(>arg_lock);
> > + up_read(>mmap_sem);
> > return error;
>
> Hm, shouldn't spin_lock()/spin_unlock() pair go as a fixup to existing code
> in a separate patch?
>
> Without them,
On Thu, Apr 25, 2019 at 05:13:53PM +0100, Dmitry Safonov wrote:
>
> diff --git a/include/linux/time_namespace.h b/include/linux/time_namespace.h
> index 8f75d34cf34a..5f0da6858b10 100644
> --- a/include/linux/time_namespace.h
> +++ b/include/linux/time_namespace.h
> @@ -48,6 +48,14 @@ static
ck and
> keep mmap_sem for reading only (analogous to what we already do in
> prctl_set_mm_map).
>
> Also, save few cycles by looking up VMA only after performing basic
> arguments validation.
>
> Signed-off-by: Michal Koutný
Reviewed-by: Cyrill Gorcunov
As Laurent men
On Thu, Apr 18, 2019 at 03:50:39PM +0200, Michal Koutný wrote:
> I learnt, it's, alas, too late to drop the non PRCTL_SET_MM_MAP calls
> [1], so at least downgrade the write acquisition of mmap_sem as in the
> patch below (that should be stacked on the previous one or squashed).
>
> Cyrill, you
On Wed, Apr 17, 2019 at 04:44:54PM +0200, Michal Koutný wrote:
> On Wed, Apr 17, 2019 at 03:38:41PM +0300, Cyrill Gorcunov
> wrote:
> > I've a bit vague memory what we've ended up with, but iirc there was
> > a problem with brk() syscall or similar. Then I think
On Wed, Apr 17, 2019 at 04:44:54PM +0200, Michal Koutný wrote:
> On Wed, Apr 17, 2019 at 03:38:41PM +0300, Cyrill Gorcunov
> wrote:
> > I've a bit vague memory what we've ended up with, but iirc there was
> > a problem with brk() syscall or similar. Then I think
On Wed, Apr 17, 2019 at 02:23:50PM +0200, Michal Koutný wrote:
> Hi.
>
> I see this discussion somewhat faded away since the previous year.
>
> There was rework [1] that reduced (ab)use of mmap_sem in prctl
> functions.
>
> Actually, there still remains the down_write() in prctl_set_mm.
> I
On Tue, Apr 09, 2019 at 12:38:25PM -0400, Vince Weaver wrote:
>
> It still crashes at the same place with this patch and my reproducible
> test case.
Thank for testing, Vince! At least now we know it is unrelated to
alias events. Will ping you once I get more ideas.
ot;,
| "mm_end_code": "0x8f5fb4",
| "mm_start_data": "0xf1bfb0",
| "mm_end_data": "0xf1bfb0",
Thus we need to change validate_prctl_map from strictly less to less or
equal operator use.
Fixes: f606b77f1a9e362451aca8f81d8f36a3a11213
On Thu, Apr 04, 2019 at 11:20:38PM +0300, Cyrill Gorcunov wrote:
> > the machine still crashes after this, but not right away.
>
> yes, exactly, if look into disasm code we will see that 0x158
> offset points to hwc from event. Vince, gimme some time, probably
> the weeke
On Thu, Apr 04, 2019 at 03:01:14PM -0400, Vince Weaver wrote:
>
> I do have a lot of this automated already from tracking down past bugs,
> but it turns out that most of the fuzzer-found bugs aren't deterministic
> so it doesn't always work.
>
> For example this bug, while I can easily repeat
On Thu, Apr 04, 2019 at 12:37:18PM -0400, Vince Weaver wrote:
> On Thu, 4 Apr 2019, Cyrill Gorcunov wrote:
>
> > On Thu, Apr 04, 2019 at 09:25:47AM -0400, Vince Weaver wrote:
> > >
> > > It looks like there are at least two bugs here, one that's a full
> >
On Thu, Apr 04, 2019 at 09:25:47AM -0400, Vince Weaver wrote:
>
> It looks like there are at least two bugs here, one that's a full
> hardlockup with nothing on serial console. The other is the NULL
> dereference.
>
Seems so. I've spent plenty of time yesterday trying to figure out how
we
On Wed, Apr 03, 2019 at 10:19:44PM +0300, Cyrill Gorcunov wrote:
>
> You know, seems I got what happened -- p4_general_events do
> not cover all general events, they stop at PERF_COUNT_HW_BUS_CYCLES,
> while more 3 general event left. This is 'cause I've not been following
> pmu ev
On Wed, Apr 03, 2019 at 10:59:32AM -0400, Vince Weaver wrote:
>
> so moving this to its own thread.
>
> There was a two-part question asked.
> 1. Can the perf-fuzzer crash a Pentium 4 system
> 2. Does anyone care anymore?
>
> The answer to #1 turns out to be "yes"
> I'm not sure
On Wed, Apr 03, 2019 at 10:59:32AM -0400, Vince Weaver wrote:
>
> so moving this to its own thread.
>
> There was a two-part question asked.
> 1. Can the perf-fuzzer crash a Pentium 4 system
> 2. Does anyone care anymore?
>
> The answer to #1 turns out to be "yes"
> I'm not sure
On Wed, Apr 03, 2019 at 05:27:54PM +0300, Cyrill Gorcunov wrote:
> On Wed, Apr 03, 2019 at 10:15:33AM -0400, Vince Weaver wrote:
> > > Mind to point me where json events should lay, I could try to convert
> > > names.
> >
> > I was mostly joking about that. But
On Wed, Apr 03, 2019 at 10:15:33AM -0400, Vince Weaver wrote:
> > Mind to point me where json events should lay, I could try to convert
> > names.
>
> I was mostly joking about that. But the event lists are in the kernel
> tree in
> tools/perf/pmu-events/arch/x86/
>
> I don't think
On Tue, Apr 02, 2019 at 05:13:15PM -0400, Vince Weaver wrote:
>
> > You know, running fuzzer on p4 might worth in anycase. As to potential
> > problems to fix -- i could try find some time slot for, still quite
> > limited too 'cause of many other duties :(
>
>
> Well I fired up the Pentium 4
>
On Tue, Apr 02, 2019 at 10:53:38AM -0400, Vince Weaver wrote:
> On Tue, 2 Apr 2019, Cyrill Gorcunov wrote:
> > On Tue, Apr 02, 2019 at 03:03:02PM +0200, Peter Zijlstra wrote:
> > > I have vague memories of the P4 thing crashing with Vince's perf_fuzzer,
> &g
On Tue, Apr 02, 2019 at 03:03:02PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 01, 2019 at 09:46:33PM +, Lendacky, Thomas wrote:
> > This patch series addresses issues with increased NMI latency in newer
> > AMD processors that can result in unknown NMI messages when PMC counters
> > are
On Wed, Feb 06, 2019 at 11:52:03AM +0300, Cyrill Gorcunov wrote:
...
> >
> > - if ((flags & ~TFD_SETTIME_FLAGS) ||
> > -!itimerspec64_valid(new))
> > - return -EINVAL;
>
> Please don't defer this early test of a @flags value. Otherwise
&
On Wed, Feb 06, 2019 at 12:10:39AM +, Dmitry Safonov wrote:
> From: Andrei Vagin
>
> Make timerfd respect timens offsets.
> Provide two helpers timens_clock_to_host() timens_clock_from_host() that
> are useful to wire up timens to different kernel subsystems.
> Following patches will use
On Wed, Jan 30, 2019 at 06:48:51PM +0300, Cyrill Gorcunov wrote:
> On Wed, Jan 30, 2019 at 03:42:45PM +, Al Viro wrote:
> > On Wed, Jan 30, 2019 at 06:39:11PM +0300, Cyrill Gorcunov wrote:
> > > And use ARRAY_SIZE for easier code modification if we ever need in future.
&g
On Wed, Jan 30, 2019 at 03:42:45PM +, Al Viro wrote:
> On Wed, Jan 30, 2019 at 06:39:11PM +0300, Cyrill Gorcunov wrote:
> > And use ARRAY_SIZE for easier code modification if we ever need in future.
>
> Umm... Why PIPE_DEF_BUFFERS, though? Because it's a constant from
And use ARRAY_SIZE for easier code modification if we ever need in future.
CC: Al Viro
Signed-off-by: Cyrill Gorcunov
---
fs/splice.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-next.git/fs/splice.c
The rcu_qs is disabling IRQs by self so no need to do the same in raise_softirq
but instead we can save some cycles using raise_softirq_irqoff directly.
CC: Paul E. McKenney
Signed-off-by: Cyrill Gorcunov
---
The prev patch body has been screwed, sorry.
kernel/rcu/tiny.c |2 +-
1 file
The rcu_qs is disabling IRQs by self so no need to do the same in raise_softirq,
instead we can save some cycles using raise_softirq_irqoff directly.
CC: Paul E. McKenney
Signed-off-by: Cyrill Gorcunov
---
kernel/rcu/tiny.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux
On Mon, Jan 14, 2019 at 11:01:20AM -0800, Matthew Wilcox wrote:
> On Mon, Jan 14, 2019 at 09:47:41PM +0300, Cyrill Gorcunov wrote:
> > Since the mark is used as an array index we should use
> > preincrement to not access the XA_MARK_MAX index.
>
> But XA_MARK_MAX is inclusiv
1 - 100 of 2647 matches
Mail list logo
