public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* RFC arch/sh/kernel/traps_64.c - unclear if/else construct
@ 2015-02-03  9:37 Nicholas Mc Guire
  2015-02-16 21:24 ` RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer) Helge Deller
  0 siblings, 1 reply; 4+ messages in thread
From: Nicholas Mc Guire @ 2015-02-03  9:37 UTC (permalink / raw)
  To: James E.J. Bottomley
  Cc: Helge Deller, Dan Carpenter, linux-parisc, linux-kernel


Hi !

 scanning for  if STATEMENT else STATEMENT  triggered here - and it does look
like it needs a fix-up or at least some comments.

<snip?
int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
{
	 int fstype;
	 ...
		  /* String could be altered by userspace after strlen_user() */
		  fsname[len - 1] = '\0';

		  printk(KERN_DEBUG "that is '%s' as (char *)\n", fsname);
		  if ( !strcmp(fsname, "hfs") ) {
			   fstype = 0;
		  } else {
			   fstype = 0;
		  }  
		     
		  kfree(fsname);

		  printk(KERN_DEBUG "returning fstype=%d\n", fstype);
		  return fstype; /* something other than default */
<snip>

 The if-else here has no effect and the printk will not convey any information
as its always fstype==0, finally the return statement comment indicates that it
should not be the default...

 Can't come up with a reasonable cleanup patch here - but this looks like it
needs a review.

thx!
hofrat

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer)
  2015-02-03  9:37 RFC arch/sh/kernel/traps_64.c - unclear if/else construct Nicholas Mc Guire
@ 2015-02-16 21:24 ` Helge Deller
  2015-02-17  8:49   ` Paul Bolle
  0 siblings, 1 reply; 4+ messages in thread
From: Helge Deller @ 2015-02-16 21:24 UTC (permalink / raw)
  To: Nicholas Mc Guire, James E.J. Bottomley
  Cc: Dan Carpenter, linux-parisc, linux-kernel

Hello Nicholas,

On 03.02.2015 10:37, Nicholas Mc Guire wrote:
>   scanning for  if STATEMENT else STATEMENT  triggered here - and it does look
> like it needs a fix-up or at least some comments.
>
> <snip?
> int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
> {
> 	 int fstype;
> 	 ...
> 		  /* String could be altered by userspace after strlen_user() */
> 		  fsname[len - 1] = '\0';
>
> 		  printk(KERN_DEBUG "that is '%s' as (char *)\n", fsname);
> 		  if ( !strcmp(fsname, "hfs") ) {
> 			   fstype = 0;
> 		  } else {
> 			   fstype = 0;
> 		  }
> 		
> 		  kfree(fsname);
>
> 		  printk(KERN_DEBUG "returning fstype=%d\n", fstype);
> 		  return fstype; /* something other than default */
> <snip>
>
>   The if-else here has no effect and the printk will not convey any information
> as its always fstype==0, finally the return statement comment indicates that it
> should not be the default...
>
>   Can't come up with a reasonable cleanup patch here - but this looks like it
> needs a review.

The hpux code is broken anyway.
I'm going to remove it from the tree.

Thanks!

Helge

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer)
  2015-02-16 21:24 ` RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer) Helge Deller
@ 2015-02-17  8:49   ` Paul Bolle
  2015-02-17 15:15     ` Helge Deller
  0 siblings, 1 reply; 4+ messages in thread
From: Paul Bolle @ 2015-02-17  8:49 UTC (permalink / raw)
  To: Helge Deller
  Cc: Valentin Rothberg, Nicholas Mc Guire, James E.J. Bottomley,
	Dan Carpenter, linux-parisc, linux-kernel

Hi Helge,

On Mon, 2015-02-16 at 22:24 +0100, Helge Deller wrote:
> The hpux code is broken anyway.
> I'm going to remove it from the tree.

That happened in commit 04c161497716 ("parisc: hpux - Drop support for
HP-UX binaries"), which is included in today's linux-next
(next-20150217). I noticed because a script I use to check linux-next
spotted a problem with it.

That commit removed the Kconfig symbol HPUX. As a result BINFMT_SOM (see
fs/Kconfig.binfmt) can't be set anymore. I assume a patch to remove that
symbol too is also part of that series. Is that correct?


Paul Bolle


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer)
  2015-02-17  8:49   ` Paul Bolle
@ 2015-02-17 15:15     ` Helge Deller
  0 siblings, 0 replies; 4+ messages in thread
From: Helge Deller @ 2015-02-17 15:15 UTC (permalink / raw)
  To: Paul Bolle
  Cc: Valentin Rothberg, Nicholas Mc Guire, James E.J. Bottomley,
	Dan Carpenter, linux-parisc, linux-kernel

H Paul,

On 17.02.2015 09:49, Paul Bolle wrote:
> On Mon, 2015-02-16 at 22:24 +0100, Helge Deller wrote:
>> The hpux code is broken anyway.
>> I'm going to remove it from the tree.
>
> That happened in commit 04c161497716 ("parisc: hpux - Drop support for
> HP-UX binaries"), which is included in today's linux-next
> (next-20150217).

Yes.

> That commit removed the Kconfig symbol HPUX. As a result BINFMT_SOM (see
> fs/Kconfig.binfmt) can't be set anymore. I assume a patch to remove that
> symbol too is also part of that series. Is that correct?

I missed it, but just sent out a patch to remove BINFMT_SOM too.
It will be in the next linux-next tree via
http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next

Helge


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-02-17 15:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-03  9:37 RFC arch/sh/kernel/traps_64.c - unclear if/else construct Nicholas Mc Guire
2015-02-16 21:24 ` RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer) Helge Deller
2015-02-17  8:49   ` Paul Bolle
2015-02-17 15:15     ` Helge Deller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox