Linus Torvalds writes:
> Alternatively, we could just limit module loading size to some (fairly
> arbitrary) big number.
Yeah, we used to do that because vmalloc would BUG rather than
returning NULL.
But you're already CAP_SYS_MODULE in this path, which kind of makes it
hard to care very much ab
On Tue, Apr 07, 2015 at 11:12:31AM -0700, Linus Torvalds wrote:
> On Apr 7, 2015 10:58 AM, "Dave Jones" wrote:
> > >
> > > +#define COPY_CHUNK_SIZE (16*PAGE_SIZE)
> >
> > This needs to be bigger, just to accomodate things like xfs, which
> > on my system is over 1mb. I think some out-of-t
On Tue, Apr 07, 2015 at 10:33:49AM -0700, Linus Torvalds wrote:
> On Tue, Apr 7, 2015 at 10:00 AM, Sasha Levin wrote:
> >
> > It locks up quickly without KASan as well.
>
> I suspect it's some virtualization artifact, where the writes cause
> COW faults (or just memory allocations) in the L
On Tue, Apr 7, 2015 at 10:00 AM, Sasha Levin wrote:
>
> It locks up quickly without KASan as well.
I suspect it's some virtualization artifact, where the writes cause
COW faults (or just memory allocations) in the L0 domain.
Whatever. It's probably not worth fighting. Either we just decide that
On 04/07/2015 10:37 AM, Ingo Molnar wrote:
>
> * Michal Hocko wrote:
>
>> On Tue 07-04-15 13:05:31, Ingo Molnar wrote:
>>>
>>> * Borislav Petkov wrote:
>>>
On Tue, Apr 07, 2015 at 11:31:45AM +0200, Ingo Molnar wrote:
> Would be nice to see the actual kernel .config, as there's a few
>>
* Michal Hocko wrote:
> On Tue 07-04-15 13:05:31, Ingo Molnar wrote:
> >
> > * Borislav Petkov wrote:
> >
> > > On Tue, Apr 07, 2015 at 11:31:45AM +0200, Ingo Molnar wrote:
> > > > Would be nice to see the actual kernel .config, as there's a few
> > > > debug features that can slow things dow
On Tue 07-04-15 13:05:31, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Tue, Apr 07, 2015 at 11:31:45AM +0200, Ingo Molnar wrote:
> > > Would be nice to see the actual kernel .config, as there's a few
> > > debug features that can slow things down significantly, such as
> > > CONFIG_K
* Borislav Petkov wrote:
> On Tue, Apr 07, 2015 at 11:31:45AM +0200, Ingo Molnar wrote:
> > Would be nice to see the actual kernel .config, as there's a few
> > debug features that can slow things down significantly, such as
> > CONFIG_KMEMCHECK=y or in some cases CONFIG_DEBUG_PAGEALLOC=y.
>
>
* Linus Torvalds wrote:
> On Mon, Apr 6, 2015 at 12:08 PM, Sasha Levin wrote:
> >
> > Your patch just makes it hang in memset instead:
>
> So it's certainly a big memset (2GB or so: original count in RDX:
> 0x7e777000, and "%rcx << 6" is bytes left, so it has done about 85%
> of it), which i
On 04/06/2015 03:36 PM, Borislav Petkov wrote:
> On Mon, Apr 06, 2015 at 03:08:24PM -0400, Sasha Levin wrote:
>> > Your patch just makes it hang in memset instead:
>> >
>> > [ 963.104556] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
>> > [trinity-c224:9845]
>> > [ 963.104556] Modules l
On Mon, Apr 6, 2015 at 12:08 PM, Sasha Levin wrote:
>
> Your patch just makes it hang in memset instead:
So it's certainly a big memset (2GB or so: original count in RDX:
0x7e777000, and "%rcx << 6" is bytes left, so it has done about 85% of
it), which is certainly going to be slow, but it should
On Mon, Apr 06, 2015 at 03:08:24PM -0400, Sasha Levin wrote:
> Your patch just makes it hang in memset instead:
>
> [ 963.104556] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
> [trinity-c224:9845]
> [ 963.104556] Modules linked in:
> [ 963.104556] irq event stamp: 3773324
> [ 963.104
On 04/06/2015 01:26 PM, Linus Torvalds wrote:
> On Sun, Apr 5, 2015 at 8:59 PM, Sasha Levin wrote:
>>
>> This is the result of getting copy_user_handle_tail to zero out a large
>> block of
>> kernel memory very inefficiently:
>
> Ugh.
>
> Normally we should be able to just do
>
> if (z
On Sun, Apr 5, 2015 at 8:59 PM, Sasha Levin wrote:
>
> This is the result of getting copy_user_handle_tail to zero out a large block
> of
> kernel memory very inefficiently:
Ugh.
Normally we should be able to just do
if (zerorest)
memset(to, 0, len);
and be done with i
On Mon, Apr 06, 2015 at 10:51:42AM -0400, Sasha Levin wrote:
> > Btw, what's happening to that user pointer in %rdi, is it kosher?
>
> Probably not. Trinity passes random addresses into that syscall, so it's
> probably one of it's magic
> values.
So what is the expectation? If that pointer goes
On Sun, Apr 05, 2015 at 11:59:52PM -0400, Sasha Levin wrote:
> Hi all,
>
> I'm seeing an interesting hang when trinity is trying to load a large module,
> where
> the size passed by userspace is larger than the amount of memory actually
> allocated
> in userspace and passed in the 'from' paramet
Hi all,
I'm seeing an interesting hang when trinity is trying to load a large module,
where
the size passed by userspace is larger than the amount of memory actually
allocated
in userspace and passed in the 'from' parameter:
[ 1549.080032] NMI watchdog: BUG: soft lockup - CPU#11 stuck for 22s!
17 matches
Mail list logo
