On Wed, 25 Feb 2015, Heinrich Schuchardt wrote:
> > I disagree strongly: it's better to first do low-risk
> > cleanups, then do any fix and other changes.
> >
> > This approach has four advantages:
> >
> > - it makes the bug fix more apparent, in the context of
> > an already cleaned up
On 25.02.2015 11:17, Ingo Molnar wrote:
>
> * David Rientjes wrote:
>
>> The problem is with the structure of your patchset. You
>> want three patches. There's one bugfix patch, a
>> preparation patch, and a feature patch. The bugfix patch
>> should come first so that it can be applied,
* David Rientjes wrote:
> The problem is with the structure of your patchset. You
> want three patches. There's one bugfix patch, a
> preparation patch, and a feature patch. The bugfix patch
> should come first so that it can be applied, possibly, to
> stable kernels and doesn't depend
On 25.02.2015 11:17, Ingo Molnar wrote:
* David Rientjes rient...@google.com wrote:
The problem is with the structure of your patchset. You
want three patches. There's one bugfix patch, a
preparation patch, and a feature patch. The bugfix patch
should come first so that it can be
On Wed, 25 Feb 2015, Heinrich Schuchardt wrote:
I disagree strongly: it's better to first do low-risk
cleanups, then do any fix and other changes.
This approach has four advantages:
- it makes the bug fix more apparent, in the context of
an already cleaned up code.
* David Rientjes rient...@google.com wrote:
The problem is with the structure of your patchset. You
want three patches. There's one bugfix patch, a
preparation patch, and a feature patch. The bugfix patch
should come first so that it can be applied, possibly, to
stable kernels and
On 24.02.2015 23:16, David Rientjes wrote:
> On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
>
>>> I'm afraid I don't understand this. The intent of the patch is to
>>> separate the max_threads logic into a new function, correct? If that's
>>> true, then I don't understand why UINT_MAX is
On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
> > I'm afraid I don't understand this. The intent of the patch is to
> > separate the max_threads logic into a new function, correct? If that's
> > true, then I don't understand why UINT_MAX is being introduced into this
> > path and passed to
On 24.02.2015 22:03, David Rientjes wrote:
> On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
>
>> diff --git a/init/main.c b/init/main.c
>> index 61b99376..21394ec 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -94,7 +94,7 @@
>> static int kernel_init(void *);
>>
>> extern void
On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
> diff --git a/init/main.c b/init/main.c
> index 61b99376..21394ec 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -94,7 +94,7 @@
> static int kernel_init(void *);
>
> extern void init_IRQ(void);
> -extern void fork_init(unsigned long);
>
PAGE_SIZE is not guaranteed to be equal to or less than 8 times the
THREAD_SIZE.
E.g. architecture hexagon may have page size 1M and thread size 4096.
This would lead to a division by zero in the calculation of max_threads.
With this patch the buggy code is moved to a separate function
On 24.02.2015 22:03, David Rientjes wrote:
On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
diff --git a/init/main.c b/init/main.c
index 61b99376..21394ec 100644
--- a/init/main.c
+++ b/init/main.c
@@ -94,7 +94,7 @@
static int kernel_init(void *);
extern void init_IRQ(void);
-extern
PAGE_SIZE is not guaranteed to be equal to or less than 8 times the
THREAD_SIZE.
E.g. architecture hexagon may have page size 1M and thread size 4096.
This would lead to a division by zero in the calculation of max_threads.
With this patch the buggy code is moved to a separate function
On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
diff --git a/init/main.c b/init/main.c
index 61b99376..21394ec 100644
--- a/init/main.c
+++ b/init/main.c
@@ -94,7 +94,7 @@
static int kernel_init(void *);
extern void init_IRQ(void);
-extern void fork_init(unsigned long);
+extern void
On 24.02.2015 23:16, David Rientjes wrote:
On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
I'm afraid I don't understand this. The intent of the patch is to
separate the max_threads logic into a new function, correct? If that's
true, then I don't understand why UINT_MAX is being
On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
I'm afraid I don't understand this. The intent of the patch is to
separate the max_threads logic into a new function, correct? If that's
true, then I don't understand why UINT_MAX is being introduced into this
path and passed to the new
16 matches
Mail list logo
