From owner-kaio@oss.sgi.com Tue Aug 7 08:13:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77FDjr26296 for kaio-outgoing; Tue, 7 Aug 2001 08:13:45 -0700 Received: from pcatlas205.cern.ch (pcatlas205.cern.ch [137.138.89.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FDfV26291 for ; Tue, 7 Aug 2001 08:13:41 -0700 Received: from there (localhost.localdomain [127.0.0.1]) by pcatlas205.cern.ch (8.11.2/8.11.2) with SMTP id f77FDYF14006 for ; Tue, 7 Aug 2001 17:13:35 +0200 Message-Id: <200108071513.f77FDYF14006@pcatlas205.cern.ch> Content-Type: text/plain; charset="iso-8859-2" From: Piotr GOLONKA To: kaio@oss.sgi.com Subject: File descriptor in siginfo. Date: Tue, 7 Aug 2001 17:13:34 +0200 X-Mailer: KMail [version 1.2.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-kaio@oss.sgi.com Precedence: bulk Hi. I just slightly modified /usr/src/linux/mm/filemap.c in order to have file descriptor passed in siginfo structure when using SIGEV_SIGNAL as notification method. As I remember, someone asked for this feature some time in the past. Maybe someone find it useful... Sorry, I wont send another patch to the patch, to the patch , etc.: here's my version of three modified routines from filemap.c: Main modifiation is adding the third argument to send_signal() which allows setting siginfo's si_fd field: In lio_complete() I put zero as this argument (anyone has better idea?), and in kaio_io_complete I get filedescriptor from the original (passed by user) kaiocb->kaio_uaiocb->aio_fildes ------------------------------------------------------------------------------- static void send_signal(sigevent_t *sigev, struct task_struct *task, int fd) { if (sigev->sigev_notify == SIGEV_SIGNAL) { struct siginfo sinfo; memset(&sinfo, 0, sizeof(sinfo)); sinfo.si_signo = sigev->sigev_signo; sinfo.si_code = SI_ASYNCIO; sinfo.si_value = sigev->sigev_value; sinfo.si_fd=fd; send_sig_info(sigev->sigev_signo, &sinfo, task); } } static int lio_complete(liocb_t *liocb, int n, int wakeup) { spin_lock(&liocb->lio_lock); liocb->lio_done += n; if (liocb->lio_nent == liocb->lio_done) { spin_unlock(&liocb->lio_lock); if (wakeup) { lock_kernel(); wake_up(&liocb->lio_wait); unlock_kernel(); } send_signal(&liocb->lio_sigevent, liocb->lio_task,0); if (liocb->lio_mode == LIO_NOWAIT) kfree(liocb); return 1; } if (!wakeup) lock_kernel(); spin_unlock(&liocb->lio_lock); return 0; } static int kaio_io_complete(kaiocb_t *kaiocb, int nbytes, int ret, int gc) { aiocb_t *uaiocb = kaiocb->kaio_uaiocb; liocb_t *liocb = kaiocb->kaio_liocb; int i; if (kaiocb->kaio_pages) { for (i = 0; i < kaiocb->kaio_npages; i++) page_cache_release(kaiocb->kaio_pages[i]); if (kaiocb->kaio_pages != &kaiocb->kaio_page_inline) kfree(kaiocb->kaio_pages); } #ifdef KAIO_STATS if (copy_to_user(&uaiocb->aio_times, &kaiocb->kaio_times, sizeof(unsigned long) * AIO_TIMES)) { ret = -EFAULT; } else #endif if (put_user(nbytes, &uaiocb->aio_return)) ret = -EFAULT; /* aio_error does not go through syscall so -ret */ else if (put_user(-ret, &uaiocb->aio_error)) ret = -EFAULT; else { send_signal(&kaiocb->kaio_sigevent, kaiocb->kaio_task, kaiocb->kaio_uaiocb->aio_fildes); //kaiocb->kaio_filp->_fileno); spin_lock(&kaio_hash_lock); if (kaiocb->kaio_suspend_wait) { lock_kernel(); kaiocb->kaio_error = -ret; wake_up(kaiocb->kaio_suspend_wait); unlock_kernel(); } else { kaiocb->kaio_error = -ret; /* gc |= (liocb && liocb->lio_mode == LIO_WAIT); */ gc = 1; if (gc) kaio_remove_hash(kaiocb); } spin_unlock(&kaio_hash_lock); if (liocb) lio_complete(liocb, 1, 1); } if (gc) { fput(kaiocb->kaio_filp); kfree(kaiocb); } return ret; } -------------------------------------------- Ah, BTW: I use kernel 2.4.2, with kaio-kern-1.3.1-2.4.2 patch and a "patch to the patch" sent by Christopher Smith to this list on : Sun, 08 Apr 2001 06:32:25 -0700 I'm trying to get it work with TCP sockets and it seems to be OK for SIGEV_SIGNAL notification method. Would be nice if SIGEV_THREAD is implemented as well. regards: Piotr Golonka CERN, European Laboratory for High Energy Physics, ATLAS Experiment e-mail:Piotr.Golonka@CERN.CH PS: This is my first hacking inside LINUX kernel, please be forbearing for a beginner. From owner-kaio@oss.sgi.com Mon Aug 13 15:45:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DMjTt22518 for kaio-outgoing; Mon, 13 Aug 2001 15:45:29 -0700 Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DMjPj22512 for ; Mon, 13 Aug 2001 15:45:25 -0700 Received: from e21.nc.us.ibm.com (e21.raleigh.ibm.com [9.37.2.58]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id RAA30860 for ; Mon, 13 Aug 2001 17:24:02 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA10828 for ; Mon, 13 Aug 2001 16:18:19 -0500 Received: from d04nms53.raleigh.ibm.com (d04nms53.raleigh.ibm.com [9.67.228.60]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7DLKP5153766 for ; Mon, 13 Aug 2001 17:20:25 -0400 Importance: Normal Subject: kaio question To: kaio@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Todd M Merriweather" Date: Mon, 13 Aug 2001 17:20:19 -0400 X-MIMETrack: Serialize by Router on D04NMS53/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/13/2001 05:20:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-kaio@oss.sgi.com Precedence: bulk KAIO patch maintainer, I am experiencing difficulty using the KAIO patch to do some relatively simple operations. When I use it on my Linux machine (kernel 2.2.17), I run out of file handles (verified by checking /proc/sys/fs/file-nr ) . The program I'm running is relatively simple. The process is basically.... - call socket to get file descriptor - connect on fd - use aio_write to send data - use sigwaitinfo to wait on event notification - close fd using pointer returned by sigwaitinfo This sequence is called many times as I am trying to mimic the process a client uses to connect to a server. This process soaks up my system's resources, but it shouldn't. The pool of file handles should not constantly increase after a certain maximum number have been allocated. Looking at the patch code there seems to be a bug, or unhandled case that prevents file descriptors from being released when aio_write completes. 'kaio_io_complete' is used to signal user applications that IO is complete and to release file descriptors. Apparently, the file descriptors are only released when used the lio_listio command. This statement 'gc |= (liocb && liocb->lio_mode == LIO_WAIT)' will only set gc == 1 if the user application is using listio to do asynchronous reads/writes. Otherwise gc == 0 since it was passed to kaio_io_complete as 0. When this code executes... if (gc) { kaio_fput(kaiocb->kaio_filp); kfree(kaiocb); } the file decsriptor won't be released nor will the aio control block be freed since gc == 0. Is this the intended behavior for the KAIO patch? If so, aio_write will eventually soak up system resources and leave the system unusable. The correction is simple, but I wanted to know if you were aware of this issue. +static int +kaio_io_complete(kaiocb_t *kaiocb, int nbytes, int ret, int gc) +{ + aiocb_t *uaiocb = kaiocb->kaio_uaiocb; + liocb_t *liocb = kaiocb->kaio_liocb; + int i; + + if (kaiocb->kaio_pages) { + + for (i = 0; i < kaiocb->kaio_npages; i++) + __free_page(kaiocb->kaio_pages[i]); + kfree(kaiocb->kaio_pages); + } + +#ifdef KAIO_STATS + if (copy_to_user(&uaiocb->aio_times, &kaiocb->kaio_times, + sizeof(unsigned long) * AIO_TIMES)) + { + ret = -EFAULT; + } else +#endif + if (put_user(nbytes, &uaiocb->aio_return)) + ret = -EFAULT; + /* aio_error does not go through syscall so -ret */ + else if (put_user(-ret, &uaiocb->aio_error)) + ret = -EFAULT; + else { + send_signal(&kaiocb->kaio_sigevent, kaiocb->kaio_task); + spin_lock(&kaio_hash_lock); + if (kaiocb->kaio_suspend_wait) { + lock_kernel(); + kaiocb->kaio_error = -ret; + wake_up(kaiocb->kaio_suspend_wait); + unlock_kernel(); + } else { + kaiocb->kaio_error = -ret; + gc |= (liocb && liocb->lio_mode == LIO_WAIT); + if (gc) + kaio_remove_hash(kaiocb); + } + spin_unlock(&kaio_hash_lock); + if (liocb) + lio_complete(liocb, 1, 1); + } + if (gc) { + kaio_fput(kaiocb->kaio_filp); + kfree(kaiocb); + } + return ret; +} Todd Merriweather IBM Software Developer SWG - AIM Testing Tools Phone: (919)254-2863 From owner-kaio@oss.sgi.com Thu Aug 16 15:41:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GMfiS12649 for kaio-outgoing; Thu, 16 Aug 2001 15:41:44 -0700 Received: from [172.16.128.29] ([209.213.209.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GMfej12645 for ; Thu, 16 Aug 2001 15:41:40 -0700 Received: from pcm_mail.preftech.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 16 Aug 2001 15:41:39 -0700 Received: by pcm_mail.preftech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 15:41:39 -0700 Message-ID: <924A60C2986448489965157B8E1F3B5B3D8AD6@pcm_mail.preftech.com> From: "Andrey.Ilinykh" To: "'kaio@oss.sgi.com'" Subject: Why kaio is not is Linux release Date: Thu, 16 Aug 2001 15:41:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C126A4.9CE267E0" Sender: owner-kaio@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C126A4.9CE267E0 Content-Type: text/plain; charset="iso-8859-1" Hi! Just a simple question. Why kaio exists as kernel patches? Why it is not included in official Linux release? Thank you, Andrey ********************************************************************** IMPORTANT NOTICE: This e-mail message is intended for the sole use of the addressee and may contain confidential information. If you are not the intended recipient or otherwise authorized to view such information, you are hereby notified that viewing such information, as well as any disclosure, copying, distribution or use of any of the information contained in or attached therein is STRICTLY PROHIBITED. If you received this e-mail in error, please reply to the sender and delete the original message. The information in this message (and any attachment) is provided for informational purposes only and does not constitute a recommendation to buy or sell any security. All information obtained from third parties is believed to be reliable but PreferredTrade, Inc. does not guarantee its accuracy or completeness. Please do not send orders by e-mail. PreferredTrade, Inc. does not accept time sensitive, action-oriented messages or transactions orders by e-mail. This includes orders to buy or sell securities. PreferredTrade, Inc. will not be held responsible for any orders sent by e-mail. PreferredTrade, Inc. reserves the right to monitor and review the content of all e-mail sent and/or received by its employees including but not limited to this e-mail address. Messages sent to or from this e-mail address will be stored and maintained until discarded. PreferredTradeSM and Preferred TradeSM are servicemarks and trademarks of PreferredTrade, Inc. All rights reserved. PreferredTrade, Inc., Member NYSE and other principal exchanges, MSRB, SIPC ********************************************************************** ------_=_NextPart_001_01C126A4.9CE267E0 Content-Type: text/html; charset="iso-8859-1" Why kaio is not is Linux release

Hi!
Just a simple question.
Why kaio exists as kernel patches? Why it is not included in official Linux release?

Thank you,
  Andrey



**********************************************************************
IMPORTANT NOTICE:

This e-mail message is intended for the sole use of the
addressee and may contain confidential information.
If you are not the intended recipient or otherwise
authorized to view such information, you are hereby
notified that viewing such information, as well as any
disclosure, copying, distribution or use of any of the
information contained in or attached therein is
STRICTLY PROHIBITED. If you received this e-mail
in error, please reply to the sender and delete the
original message.

The information in this message (and any attachment) is
provided for informational purposes only and does not
constitute a recommendation to buy or sell any security.
All information obtained from third parties is believed to be
reliable but PreferredTrade, Inc. does not guarantee its
accuracy or completeness.

Please do not send orders by e-mail. PreferredTrade, Inc.
does not accept time sensitive, action-oriented messages
or transactions orders by e-mail. This includes orders to
buy or sell securities. PreferredTrade, Inc. will not be
held responsible for any orders sent by e-mail.

PreferredTrade, Inc. reserves the right to monitor and
review the content of all e-mail sent and/or received by
its employees including but not limited to this e-mail
address. Messages sent to or from this e-mail address
will be stored and maintained until discarded.

PreferredTradeSM and Preferred TradeSM are
servicemarks and trademarks of PreferredTrade, Inc.
All rights reserved.

PreferredTrade, Inc., Member NYSE and other principal
exchanges, MSRB, SIPC
**********************************************************************
 ------_=_NextPart_001_01C126A4.9CE267E0--