Just a follow up, since I said I would come back around this week.
I've come up with a couple patchsets that I'm going to attempt to test
internally before I sent out more widely. I'm thinking it's
appropriate to mail out two changes:
(1) Reject attempts to map physical memory addresses outside
Sounds good. Thanks for the context.
I'll keep this on my plate and I'll turn something around once I've
had a chance to test a bit, probably next week.
On Fri, Oct 27, 2017 at 1:24 PM, Ingo Molnar wrote:
>
> * Craig Bergstrom wrote:
>
>> Reverting seems like the right approach at the moment.
* Craig Bergstrom wrote:
> Reverting seems like the right approach at the moment. My apologies
> for the breakage so late the in the cycle.
Note that there's no need for you to apologize and you carry exactly zero
amount
of blame for the late-cycle breakage: it was my decision to send it to
* Linus Torvalds wrote:
> On Thu, Oct 26, 2017 at 9:02 PM, Ingo Molnar wrote:
> >
> > Well, 'mem=2048M' shouldn't really limit device memory, it's supposed to
> > limit
> > (trim) 'RAM' and not much else.
>
> Agreed. You should very much be able to map in IO memory or whatever
> above the 2G
>>> On 26.10.17 at 21:29, wrote:
> On 26/10/17 19:49, Craig Bergstrom wrote:
>> Sander, thanks for the details, they've been very useful.
>>
>> I suspect that your host system's mem=2048M parameter is causing the
>> problem. Any chance you can confirm by removing the parameter and
>> running the
On Thu, Oct 26, 2017 at 9:50 PM, Craig Bergstrom wrote:
> Reverting seems like the right approach at the moment. My apologies
> for the breakage so late the in the cycle.
>
> Post-revert, there remains a bug here wherein you can make the system
> OOPS if you mmap memory above the 48 bit bus width
On 26/10/17 20:29, Sander Eikelenboom wrote:
> On 26/10/17 19:49, Craig Bergstrom wrote:
>> Sander, thanks for the details, they've been very useful.
>>
>> I suspect that your host system's mem=2048M parameter is causing the
>> problem. Any chance you can confirm by removing the parameter and
>> r
Reverting seems like the right approach at the moment. My apologies
for the breakage so late the in the cycle.
Post-revert, there remains a bug here wherein you can make the system
OOPS if you mmap memory above the 48 bit bus width. Linus/Ingo, is
there something in particular that you'd like to
On Thu, Oct 26, 2017 at 9:02 PM, Ingo Molnar wrote:
>
> Well, 'mem=2048M' shouldn't really limit device memory, it's supposed to limit
> (trim) 'RAM' and not much else.
Agreed. You should very much be able to map in IO memory or whatever
above the 2G address even if the high_memory itself might b
On 26/10/17 19:49, Craig Bergstrom wrote:
> Sander, thanks for the details, they've been very useful.
>
> I suspect that your host system's mem=2048M parameter is causing the
> problem. Any chance you can confirm by removing the parameter and
> running the guest code path?
I removed it, but kept
* Craig Bergstrom wrote:
> Sander, thanks for the details, they've been very useful.
>
> I suspect that your host system's mem=2048M parameter is causing the
> problem. Any chance you can confirm by removing the parameter and
> running the guest code path?
>
> More specifically, since you're
Sander, thanks for the details, they've been very useful.
I suspect that your host system's mem=2048M parameter is causing the
problem. Any chance you can confirm by removing the parameter and
running the guest code path?
More specifically, since you're telling the kernel that it's high
memory a
* Craig Bergstrom wrote:
> Yes, not much time left for 4.14, it might be reasonable to pull the
> change out since it's causing problems. [...]
Ok, I'll queue up a revert tomorrow morning and send it to Linus ASAP if
there's
no good fix by then. In hindsight I should have queued it for v4.15
Yes, not much time left for 4.14, it might be reasonable to pull the
change out since it's causing problems. The 0day testing robot
failure is relatively simple (definitely aided by the reproduction
instructions), but I'm still pulling apart the qemu failure.
Another alternative that I considered
On 26/10/17 10:12, Sander Eikelenboom wrote:
> On 26/10/17 10:05, Sander Eikelenboom wrote:
>> On 26/10/17 00:02, Craig Bergstrom wrote:
>>> Thanks for the notification, my apologies for the breakage. I'll take a
>>> close look and see if I can figure out what went wrong.
>>>
>>> Sander, any chanc
On 26/10/17 00:02, Craig Bergstrom wrote:
> Thanks for the notification, my apologies for the breakage. I'll take a
> close look and see if I can figure out what went wrong.
>
> Sander, any chance you can send /proc/iomem and the inputs to the mmap call
> that fail on your affected system?
Hi Cr
On 26/10/17 10:05, Sander Eikelenboom wrote:
> On 26/10/17 00:02, Craig Bergstrom wrote:
>> Thanks for the notification, my apologies for the breakage. I'll take a
>> close look and see if I can figure out what went wrong.
>>
>> Sander, any chance you can send /proc/iomem and the inputs to the mma
On 10/23/2017 10:44 PM, Fengguang Wu wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit ce56a86e2ade45d052b3228cdfebe913a1ae7381
> Author: Craig Bergstrom
> A
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit ce56a86e2ade45d052b3228cdfebe913a1ae7381
Author: Craig Bergstrom
AuthorDate: Thu Oct 19 13:28:56 2017 -0600
Commit: Ingo
19 matches
Mail list logo
