x86: DS cleanup - dont treat 0 as NULL

PATCH In review Cyrill Gorcunov 4 participants 9 messages Apr 28, 2008 – Apr 29, 2008 x86

lore

Share & tools

lore

Cyrill Gorcunov

author

2008-04-28 19:16 UTC #0 lore raw

PATCH 1/1 x86: DS cleanup - dont treat 0 as NULL

Signed-off-by Cyrill Gorcunov <[email protected]>

---

Actually I wonder why in original code Atom processors was _that_ aligned? Was it made with a special purpose? yes, it's a mobile platform, but can't see any reason for such alignment.

 arch/x86/kernel/ds.c |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

arch/x86/kernel/ds.c +9 -9

index 5b32b6d..24a323c 100644
@@ -238,12 +238,12 @@ static inline struct ds_context *ds_alloc_context(struct task_struct *task)
 		context = kzalloc(sizeof(*context), GFP_KERNEL);
 
 		if (!context)
-			return 0;
+			return NULL;
 
 		context->ds = kzalloc(ds_cfg.sizeof_ds, GFP_KERNEL);
 		if (!context->ds) {
 			kfree(context);
-			return 0;
+			return NULL;
 		}
 
 		*p_context = context;

@@ -279,7 +279,7 @@ static inline void ds_put_context(struct ds_context *context)
 	if (--context->count)
 		goto out;
 
-	*(context->this) = 0;
+	*(context->this) = NULL;
 
 	if (context->task)
 		clear_tsk_thread_flag(context->task, TIF_DS_AREA_MSR);

@@ -341,16 +341,16 @@ static inline void *ds_allocate_buffer(size_t size, unsigned int *pages)
 	rlim = current->signal->rlim[RLIMIT_AS].rlim_cur >> PAGE_SHIFT;
 	vm   = current->mm->total_vm  + pgsz;
 	if (rlim < vm)
-		return 0;
+		return NULL;
 
 	rlim = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur >> PAGE_SHIFT;
 	vm   = current->mm->locked_vm  + pgsz;
 	if (rlim < vm)
-		return 0;
+		return NULL;
 
 	buffer = kzalloc(size, GFP_KERNEL);
 	if (!buffer)
-		return 0;
+		return NULL;
 
 	current->mm->total_vm  += pgsz;
 	current->mm->locked_vm += pgsz;

@@ -395,7 +395,7 @@ static int ds_request(struct task_struct *task, void *base, size_t size,
 	if (context->owner[qual] == current)
 		goto out_unlock;
 	error = -EPERM;
-	if (context->owner[qual] != 0)
+	if (context->owner[qual] != NULL)
 		goto out_unlock;
 	context->owner[qual] = current;

@@ -445,7 +445,7 @@ static int ds_request(struct task_struct *task, void *base, size_t size,
 	return error;
 
  out_release:
-	context->owner[qual] = 0;
+	context->owner[qual] = NULL;
 	ds_put_context(context);
 	return error;

@@ -825,7 +825,7 @@ void __cpuinit ds_init_intel(struct cpuinfo_x86 *c)
 			ds_configure(&ds_cfg_var);
 			break;
 		case 0xF: /* Core2 */
-        case 0x1C: /* Atom */
+		case 0x1C: /* Atom */
 			ds_configure(&ds_cfg_64);
 			break;
 		default:

H. Peter Anvin

reviewer

2008-04-28 19:46 UTC #1 lore raw

Quoted 6 lines · Cyrill Gorcunov

Actually I wonder why in original code Atom processors was _that_ aligned? Was it made with a special purpose? yes, it's a mobile platform, but can't see any reason for such alignment.

I'm sorry, I don't see how this comment has anything to do with this patch?

-hpa

H. Peter Anvin

reviewer

2008-04-28 19:47 UTC #2 lore raw

In reply to Cyrill Gorcunov

Quoted 6 lines · Cyrill Gorcunov

Actually I wonder why in original code Atom processors was _that_ aligned? Was it made with a special purpose? yes, it's a mobile platform, but can't see any reason for such alignment.

[...]

arch/x86/kernel/ds.c void __cpuinit ds_init_intel(struct cpuinfo_x86 *c) · line 831

Quoted 10 lines

arch/x86/kernel/ds.c +1 -1

@@ -825,7 +825,7 @@ void __cpuinit ds_init_intel(struct cpuinfo_x86 *c)
 			ds_configure(&ds_cfg_var);
 			break;
 		case 0xF: /* Core2 */
-        case 0x1C: /* Atom */
+		case 0x1C: /* Atom */
 			ds_configure(&ds_cfg_64);
 			break;
 		default:

Nevermind, I was looking for a *memory* alignment... :-/

-hpa

Cyrill Gorcunov

author

2008-04-28 20:00 UTC #3 lore raw

Oh, my fault, i had to be more concrete :(

Ingo Molnar

2008-04-28 20:03 UTC #4 lore raw

In reply to Cyrill Gorcunov

Quoted 1 line · Cyrill Gorcunov

Signed-off-by Cyrill Gorcunov <[email protected]>

thanks Cyrill, applied.

arch/x86/kernel/ds.c void __cpuinit ds_init_intel(struct cpuinfo_x86 *c) · line 830

Quoted 8 lines

arch/x86/kernel/ds.c +1 -1

@@ -825,7 +825,7 @@ void __cpuinit ds_init_intel(struct cpuinfo_x86 *c)
 			ds_configure(&ds_cfg_var);
 			break;
 		case 0xF: /* Core2 */
-        case 0x1C: /* Atom */
+		case 0x1C: /* Atom */
 			ds_configure(&ds_cfg_64);
 			break;

to me it looks like a typo, not a sign of any real bug/thinko. The processor IDs there are a flat list.

Ingo

David Newall

2008-04-29 06:23 UTC #5 lore raw

In reply to Cyrill Gorcunov

Review

Quoted 2 lines · Cyrill Gorcunov

(quoted diff) +1 -1
-			return 0;
+			return NULL;

Why? The constant 0 is C's official symbol for a null pointer.

H. Peter Anvin

reviewer

2008-04-29 06:41 UTC #6 lore raw

Quoted 5 lines · David Newall

Review
Quoted 2 lines · Cyrill Gorcunov
(quoted diff) +1 -1
-			return 0;
+			return NULL;
Why? The constant 0 is C's official symbol for a null pointer.

It's still bad style.

-hpa

David Newall

2008-04-29 17:40 UTC #7 lore raw

Quoted 8 lines · H. Peter Anvin

Quoted 5 lines · David Newall
Review
Quoted 2 lines · Cyrill Gorcunov
(quoted diff) +1 -1
-            return 0;
+            return NULL;
Why? The constant 0 is C's official symbol for a null pointer.
It's still bad style.

I disagree, but I don't want to debate the point.

Cyrill Gorcunov

author

2008-04-29 07:50 UTC #8 lore raw

In reply to David Newall

Quoted 6 lines · David Newall

Review
Quoted 2 lines · Cyrill Gorcunov
(quoted diff) +1 -1
-                     return 0;
+                     return NULL;
Why? The constant 0 is C's official symbol for a null pointer.

Yes, but by using NULL explicilty allows you to separate _pointers_ from numbers on review process. Or maybe you wanna drop NULL at all? I dont think you will like that ;)