public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <dvhltc@us.ibm.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Bug: fio traps into kernel without exiting because futex has a deadloop
Date: Thu, 11 Jun 2009 16:33:16 +0800	[thread overview]
Message-ID: <1244709196.2560.287.camel@ymzhang> (raw)
In-Reply-To: <1244701128.6691.5.camel@laptop>

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Thu, 2009-06-11 at 08:18 +0200, Peter Zijlstra wrote:
> On Thu, 2009-06-11 at 07:55 +0200, Peter Zijlstra wrote:
> > On Thu, 2009-06-11 at 11:08 +0800, Zhang, Yanmin wrote:
> > > I investigate a fio hang issue. When I run fio multi-process
> > > testing on many disks, fio traps into kernel and doesn't exit
> > > (mostly hit once after runing sub test cases for hundreds of times).
> > > 
> > > Oprofile data shows kernel consumes time with some futex functions.
> > > Command kill couldn't kill the process and machine reboot also hangs.
> > > 
> > > Eventually, I locate the root cause as a bug of futex. Kernel enters
> > > a deadloop between 'retry' and 'goto retry' in function futex_wake_op.
> > > By unknown reason (might be an issue of fio or glibc), parameter uaddr2
> > > points to an area which is READONLY. So futex_atomic_op_inuser returns
> > > -EFAULT when trying to changing the data at uaddr2, but later get_user
> > > still succeeds becasue the area is READONLY. Then go back to retry.
> > > 
> > > I create a simple test case to trigger it, which just shmat an READONLY
> > > area for address uaddr2.
> > > 
> > > It could be used as a DOS attack.
> 
> /me has morning juice and notices he sent the wrong commit...
> 
> commit 64d1304a64477629cb16b75491a77bafe6f86963
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Mon May 18 21:20:10 2009 +0200
2.6.30 includes the new commit. I did a quick testing with my simple
test case and it traps into kernel without exiting.

The reason is I use flag FUTEX_PRIVATE_FLAG. So the fshared part in function
get_futex_key should be deleted. That might hurt performance.

Yanmin


[-- Attachment #2: my_futex.c --]
[-- Type: text/x-csrc, Size: 1501 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <linux/futex.h>
#include <sys/time.h>
#define _GNU_SOURCE        /* or _BSD_SOURCE or _SVID_SOURCE */
#include <unistd.h>
#include <sys/syscall.h>   /* For SYS_xxx definitions */
#include <sys/types.h>
#include <sys/shm.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <errno.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/wait.h>
#include <sys/utsname.h>


#define PAGE_SIZE	(4096)
int addr1=1;


int my_shmget(key_t key, int page_count, int *shmid, void **shmaddr)
{
	int     i, j, k;
	void    *start_addr = NULL;

	if ((*shmid =shmget(key, PAGE_SIZE*page_count, IPC_CREAT|0666 )) < 0) {
		perror("Failure:");
		return -1;
	}

	*shmaddr = shmat(*shmid, start_addr, SHM_RDONLY) ;
	if (*shmaddr == (void *) -1) {
		perror("shmget:Shared Memory Attach Failure:");
		shmctl(*shmid, IPC_RMID, NULL);
		return -1;
	}

	return 0;
}

int my_shmput(int shmid, void *shmaddr)
{
	if (shmdt((const void *)shmaddr) != 0) {
		perror("Detached Failure:");
		return -1;
	}
	if(shmctl(shmid, IPC_RMID, NULL) != 0) {
		perror("Remove shm id of htlb page failure!\n");
		return -1;
	}

	return 0;
}

int main()
{
	int * uaddr = &addr1, *uaddr2;
	void * lp;
	int ret;
	int shmid;
	void *shmaddr;

	if(my_shmget(10673861, 10, &shmid, &shmaddr))
		exit(0);

	uaddr2 = shmaddr;

	//uaddr2 = 0;

	ret = syscall(__NR_futex, uaddr, FUTEX_WAKE_OP|FUTEX_PRIVATE_FLAG, 1, NULL, uaddr2, 1);

	printf("ret=%d\n", ret);

	my_shmput(shmid, shmaddr);

	return 0;
}


  parent reply	other threads:[~2009-06-11  8:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-11  3:08 Bug: fio traps into kernel without exiting because futex has a deadloop Zhang, Yanmin
2009-06-11  5:55 ` Peter Zijlstra
2009-06-11  6:18   ` Peter Zijlstra
2009-06-11  6:21     ` Darren Hart
2009-06-11  8:33     ` Zhang, Yanmin [this message]
2009-06-11  9:36       ` Peter Zijlstra
2009-06-11 11:36       ` Peter Zijlstra
2009-06-12  0:59         ` Zhang, Yanmin
2009-06-12  8:12           ` Thomas Gleixner
2009-06-12  8:39             ` Thomas Gleixner
2009-06-15  6:03               ` Zhang, Yanmin
2009-06-15  7:57                 ` Thomas Gleixner
2009-06-16  3:16                   ` Zhang, Yanmin
2009-06-15  8:27                 ` Thomas Gleixner
2009-06-15  8:27                 ` Peter Zijlstra
2009-06-11  5:58 ` Darren Hart
2009-06-11  6:05   ` Zhang, Yanmin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1244709196.2560.287.camel@ymzhang \
    --to=yanmin_zhang@linux.intel.com \
    --cc=dvhltc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox