Re: [linux-usb-devel] [RFC] g_serial: Real tty device passthrough.
On Fri, Mar 09, 2007 at 03:25:58PM -0400, Felipe Balbi wrote: 2. Ask about opinions and suggestions for doing this in an elegant way. We don't like to write throw-away code. It should go into mainline and also be used for other projects. Just to get it right. You suggest to extend g_serial for communication with another driver and write some glue which communicates with g_serial on the one and ttySAC0 on the other side? I could life with that solution, but why not extend g_serial with a paramter to communicate directly with another tty? Yep... this could be done... actually it's not that difficult, check the code here: #define GS_MAJOR 127 #define GS_MINOR_START 0 I think the first test here is to change this two defines for you MAJOR and MINOR numbers, the ones for /dev/ttySACx Sory, but WTF? Why would changing the major/minor device numbers of g_serial do anything to solve _any_ problem (not even talking about the specific problem here)? We haev: 1) A linux based embedded device 2) a physical serial port (doesn't matter that there's a GSM Modem behind it) that uses the standard kernel serial driver interface 3) a USB device controller for the standard kernel gadget system 4) the standard g_serial driver for the gadget framework, which creates a virtual serial port on the device and a virtual usb serial port on the host What we are trying to do is to export a physical serial port as a virtual serial port over the usb device controller. Thus, the 'virtual serial device' part of g_serial needs to be cleanly separated from the 'usb serial device emulation' of g_serial, and then spliced with the physical serial device. Maybe you'll need some other work for this to work fine... I'll be reading Samsung's s3c2410 serial code to check how to connect them... There is nothing specific to the samsung in this whole discussion, so I don't see how any of that reading would bring you any further, sorry. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
On Wed, Sep 20, 2006 at 06:28:15PM -0700, David Brownell wrote: On Wednesday 20 September 2006 10:58 am, Harald Welte wrote: When a control-out transfer takes, the host controller sends a SETUP packet followed by as many OUT/DATA packets as necessary to transfer the data, but no zero-length OUT/DATA. There is a zero-length IN packet to terminate the transfer (the status stage), but that's present regardless of the amount of data. This really solves my problem. One fundamental problem (at least given the SAM7 register set) remains: I have no indication to decide which of the data OUT packets was the last, and when the device should return the status stage IN packet. The at91_udc driver should work on those at91sam7 parts, and I think some uClinux folk have done just that. AT91SAM7 != AT91RM9200. I don't think anyone runs [uC]linux in devices with 64/128k flash and half that amount of RAM. And then, I need all those resources for the actual job, not an OS. So I'm developing everything from the bare hardware onwards. Actually, DFU is the only part missing. Yesterday I finally got the USB side of DFU working, thanks to Alan's comments. So once again thanks for all of your help, time to close the thread, issue resolved :) -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpwn2Snok886.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Large control write transfers / zero-length-packet at end
Hi! I'm currently writing a USB device firmware for a Free Software / Free hardware project based on an AT91SAM7 (see http://www.openpcd.org/) In order to implement USB DFU (device firmware upgrade), I need support for big control out transfers (larger than the 8 byte control endpoint size). I suppose this is a rarely used feature, since most control transfers are used to read information from a device (control in transfers). When I use libusb / usbdevio on a 2.6.17.13 kernel to send a control out transfer of e.g. 256 bytes, then I expect it to create 32 usb data out packets of each 8 bytes size, plus one zero-length packet to terminate the transfer. I'm using usb_control_msg() to do the transfer. However, on the AT91SAM7 I only see the 32 usb data out packets, and no ZLP (zero-length-packet). Transfers of an non-modulo-eight size (e.g. 31 packets of 8 bytes, plus one four-byte packet) work perfectly fine, since in this case no ZLP is supposed to be at the end of the transfer. The host controller is UHCI in this case. Am I somehow assuming something wrong? Is there anything at all on the host software stack that controls the generation of a ZLP at the end of the transfer, or is this all done by the host controller? Any other ideas? -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpGdFq1Bk9sq.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
Hi, Alan (still remember meeting you at OLS in one of the past years!) Your assumption is wrong. thanks for your quick response. When a control-out transfer takes, the host controller sends a SETUP packet followed by as many OUT/DATA packets as necessary to transfer the data, but no zero-length OUT/DATA. There is a zero-length IN packet to terminate the transfer (the status stage), but that's present regardless of the amount of data. This really solves my problem. One fundamental problem (at least given the SAM7 register set) remains: I have no indication to decide which of the data OUT packets was the last, and when the device should return the status stage IN packet. Since (at least in my application, don't know whether this is how it is supposed to work) the setup state states the length of the data, I simply use this as indication. Seems to work just fine now. I spent already more than one day at this problem ;( Thanks once again. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpjRPpAP3Dc4.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] Make usbdevice_fs.h (again) useable from userspace
Make usbdevice_fs.h (again) useable from userspace
If we have CONFIG_COMPAT enabled, then userspace programs using
usbdevice_fs.h won't compile anymore.
Signed-off-by: Harald Welte [EMAIL PROTECTED]
---
commit 17c6b20f34d9d68918346af2a2eb6433b09af0e3
tree 397763d1e6776163d45d97702a54d352295940c2
parent b3d70298da3a00f29dd82cf16c1f13407ad2ac09
author Harald Welte [EMAIL PROTECTED] Mon, 14 Nov 2005 18:34:23 +0100
committer Harald Welte [EMAIL PROTECTED] Mon, 14 Nov 2005 18:34:23 +0100
include/linux/usbdevice_fs.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/usbdevice_fs.h b/include/linux/usbdevice_fs.h
--- a/include/linux/usbdevice_fs.h
+++ b/include/linux/usbdevice_fs.h
@@ -123,6 +123,7 @@ struct usbdevfs_hub_portinfo {
char port [127];/* e.g. port 3 connects to device 27 */
};
+#ifdef __KERNEL__
#ifdef CONFIG_COMPAT
#include linux/compat.h
struct usbdevfs_urb32 {
@@ -147,6 +148,7 @@ struct usbdevfs_ioctl32 {
compat_caddr_t data;
};
#endif
+#endif
#define USBDEVFS_CONTROL _IOWR('U', 0, struct usbdevfs_ctrltransfer)
#define USBDEVFS_BULK _IOWR('U', 2, struct usbdevfs_bulktransfer)
--
- Harald Welte [EMAIL PROTECTED] http://gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
pgpgWHub7dugB.pgp
Description: PGP signature
[linux-usb-devel] Re: [PATCH] Make usbdevice_fs.h (again) useable from userspace
On Mon, Nov 14, 2005 at 06:45:27PM +0100, Arjan van de Ven wrote: On Mon, 2005-11-14 at 18:37 +0100, Harald Welte wrote: Make usbdevice_fs.h (again) useable from userspace If we have CONFIG_COMPAT enabled, then userspace programs using usbdevice_fs.h won't compile anymore. how does the userspace application set CONFIG_COMPAT?? duh. good question. Seems like the application was broken by somehow including config.h, so we can safely ignore this. Sorry for the noise. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgphe2UtFvOtI.pgp Description: PGP signature
[linux-usb-devel] Re: [vendor-sec] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, Oct 11, 2005 at 04:44:41PM -0700, Linus Torvalds wrote: I _think_ I fixed the disconnect thing too, although I think Harald's naming for the disconnect structure was cleaner, so I wouldn't mind having a (tested) patch on top of mine.. [...] But for 2.6.14, the most important thing would be to verify that the oops cannot happen, and that you can't send signals to setuid programs by doing an open(usb) + fork(keep it open in the child) + exec(suid in the parent) I'm busy giving a netfilter tutorial all day, but I'll do the incremental patch + testing tonight. So I expect some kind of reply on this at about 11pm (GMT+1). Sorry once again for the delays, but as I said initially: I'm neither a core kernel / scheduler nor a USB developer. If somebody else had taken the bug, we'd have had way less round-trips... Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpFeVTPyRWbw.pgp Description: PGP signature
[linux-usb-devel] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Mon, Oct 10, 2005 at 11:07:45AM -0700, Chris Wright wrote:
* Harald Welte ([EMAIL PROTECTED]) wrote:
diff --git a/kernel/signal.c b/kernel/signal.c
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1193,6 +1193,40 @@ kill_proc_info(int sig, struct siginfo *
return error;
}
+/* like kill_proc_info(), but doesn't use uid/euid of current */
Maybe additional comment reminding that you most likely don't want this
interface.
Also, looks like there's same issue again:
Mh, didn't hit that bug since I don't use disconnect signals. But it
looks like it has the same issue.
Please consider the patch below, it
1) changes pid_t to uid_t
2) exports the symbol
3) adresses the same task_struct referencing issue for disconnect
signals
I hope this now finally is the last take ;)
[USBDEVIO] Fix Oops in usbdevio async URB completion (CAN-2005-3055)
If a process issues an URB from userspace and (starts to) terminate
before the URB comes back, we run into the issue described above. This
is because the urb saves a pointer to current when it is posted to the
device, but there's no guarantee that this pointer is still valid
afterwards.
This basically means that any userspace process with permissions to
any arbitrary USB device can Ooops any kernel.(!)
In fact, there are two separate issues:
1) the pointer to current can become invalid, since the task could be
completely gone when the URB completion comes back from the device.
2) Even if the saved task pointer is still pointing to a valid task_struct,
task_struct-sighand could have gone meanwhile. Therefore, the USB
async URB completion handler needs to reliably check whether
task_struct-sighand is still valid or not. In order to prevent a
race with __exit_sighand(), it needs to grab a
read_lock(tasklist_lock). This strategy seems to work, since the
send_sig_info() code uses the same protection.
However, we now would need to export a __send_sig_info() function, one
that expects to be called with read_lock(tasklist_lock) already held by
the caller.
So what we do instead, is to save the PID of the process, and introduce a
new kill_proc_info_as_uid() function. Yes, pid's can and will wrap, so
this is just a short-term fix until usbfs2 will appear.
Signed-off-by: Harald Welte [EMAIL PROTECTED]
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -30,6 +30,8 @@
* Revision history
*22.12.1999 0.1 Initial release (split from proc_usb.c)
*04.01.2000 0.2 Turned into its own filesystem
+ *30.09.2005 0.3 Fix user-triggerable oops in async URB delivery
+ * (CAN-2005-3055)
*/
/*/
@@ -58,7 +60,8 @@ static struct class *usb_device_class;
struct async {
struct list_head asynclist;
struct dev_state *ps;
- struct task_struct *task;
+ pid_t pid;
+ uid_t uid, euid;
unsigned int signr;
unsigned int ifnum;
void __user *userbuffer;
@@ -290,7 +293,8 @@ static void async_completed(struct urb *
sinfo.si_errno = as-urb-status;
sinfo.si_code = SI_ASYNCIO;
sinfo.si_addr = as-userurb;
- send_sig_info(as-signr, sinfo, as-task);
+ kill_proc_info_as_uid(as-signr, sinfo, as-pid, as-uid,
+ as-euid);
}
wake_up(ps-wait);
}
@@ -525,9 +529,11 @@ static int usbdev_open(struct inode *ino
INIT_LIST_HEAD(ps-async_pending);
INIT_LIST_HEAD(ps-async_completed);
init_waitqueue_head(ps-wait);
- ps-discsignr = 0;
- ps-disctask = current;
- ps-disccontext = NULL;
+ ps-disc.signr = 0;
+ ps-disc.pid = current-pid;
+ ps-disc.uid = current-uid;
+ ps-disc.euid = current-euid;
+ ps-disc.context = NULL;
ps-ifclaimed = 0;
wmb();
list_add_tail(ps-list, dev-filelist);
@@ -988,7 +994,9 @@ static int proc_do_submiturb(struct dev_
as-userbuffer = NULL;
as-signr = uurb-signr;
as-ifnum = ifnum;
- as-task = current;
+ as-pid = current-pid;
+ as-uid = current-uid;
+ as-euid = current-euid;
if (!(uurb-endpoint USB_DIR_IN)) {
if (copy_from_user(as-urb-transfer_buffer, uurb-buffer,
as-urb-transfer_buffer_length)) {
free_async(as);
@@ -1203,8 +1211,8 @@ static int proc_disconnectsignal(struct
return -EFAULT;
if (ds.signr != 0 (ds.signr SIGRTMIN || ds.signr SIGRTMAX))
return -EINVAL;
- ps-discsignr = ds.signr;
- ps-disccontext = ds.context;
+ ps-disc.signr = ds.signr;
+ ps-disc.context = ds.context;
return 0;
}
diff --git a/drivers/usb/core/inode.c b/drivers/usb/core/inode.c
--- a/drivers/usb/core
Re: [linux-usb-devel] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Mon, Oct 10, 2005 at 04:03:13PM -0400, Alan Stern wrote:
On Mon, 10 Oct 2005, Harald Welte wrote:
+ if ((!info || ((unsigned long)info != 1
+ (unsigned long)info != 2 SI_FROMUSER(info)))
+(euid ^ p-suid) (euid ^ p-uid)
+(uid ^ p-suid) (uid ^ p-uid)) {
No doubt this was copied from somewhere else. But why do people go to the
effort of confusing readers by using ^ instead of !=? These aren't
bit-oriented values.
Well, I'd rather keep the new code as close as possible to the original
check_permission() code, to make it obvious that it's basically doing
the same thing. I think if you want to clean this up, it could be an
additional patch on top of mine (once there is a final version and it
gets merged.
Alan Stern
--
- Harald Welte [EMAIL PROTECTED] http://gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
pgpXdDcXAf2zQ.pgp
Description: PGP signature
[linux-usb-devel] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Fri, Sep 30, 2005 at 03:16:28PM -0700, Linus Torvalds wrote:
On Sat, 1 Oct 2005, Harald Welte wrote:
please find the patch below. It compiles, but I didn't yet have the
time to verify it makes the bug disappear and the async urb delivery is
still working.
No, you can't re-use check_kill_permissions() like this, even though I
do understand the appeal.
The generic kill permissions check things like the current session, and
whether the caller has extra permissions, neither of which is sensible in
the context of group_send_sig_info_as_uid(). So you do need to write out
the uid/euid checks separately, and have a different function for this
thing.
Sorry, I've been busy, mostly with the annual netfilter developer
workshop. What about the following proposed fix:
[USBDEVIO] Fix Oops in usbdevio async URB completion (CAN-2005-3055)
If a process issues an URB from userspace and (starts to) terminate
before the URB comes back, we run into the issue described above. This
is because the urb saves a pointer to current when it is posted to the
device, but there's no guarantee that this pointer is still valid
afterwards.
This basically means that any userspace process with permissions to
any arbitrary USB device can Ooops any kernel.(!)
In fact, there are two separate issues:
1) the pointer to current can become invalid, since the task could be
completely gone when the URB completion comes back from the device.
2) Even if the saved task pointer is still pointing to a valid task_struct,
task_struct-sighand could have gone meanwhile. Therefore, the USB
async URB completion handler needs to reliably check whether
task_struct-sighand is still valid or not. In order to prevent a
race with __exit_sighand(), it needs to grab a
read_lock(tasklist_lock). This strategy seems to work, since the
send_sig_info() code uses the same protection.
However, we now would need to export a __send_sig_info() function, one
that expects to be called with read_lock(tasklist_lock) already held by
the caller.
So what we do instead, is to save the PID of the process, and introduce a
new kill_proc_info_as_uid() function. Yes, pid's can and will wrap, so
this is just a short-term fix until usbfs2 will appear.
Signed-off-by: Harald Welte [EMAIL PROTECTED]
---
commit c630b8abcd6aa848c2b2b2e546820fa0a7dd0736
tree 0b48db1d918299cc07311b01b2a2dbc8c592a852
parent e759eaa9e9e92330c5fcfd760d767d4f39375a03
author Harald Welte [EMAIL PROTECTED] Mon, 10 Oct 2005 19:42:46 +0200
committer Harald Welte [EMAIL PROTECTED] Mon, 10 Oct 2005 19:42:46 +0200
drivers/usb/core/devio.c | 12 +---
include/linux/sched.h|1 +
kernel/signal.c | 34 ++
3 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -30,6 +30,8 @@
* Revision history
*22.12.1999 0.1 Initial release (split from proc_usb.c)
*04.01.2000 0.2 Turned into its own filesystem
+ *30.09.2005 0.3 Fix user-triggerable oops in async URB delivery
+ * (CAN-2005-3055)
*/
/*/
@@ -58,7 +60,8 @@ static struct class *usb_device_class;
struct async {
struct list_head asynclist;
struct dev_state *ps;
- struct task_struct *task;
+ pid_t pid;
+ pid_t uid, euid;
unsigned int signr;
unsigned int ifnum;
void __user *userbuffer;
@@ -290,7 +293,8 @@ static void async_completed(struct urb *
sinfo.si_errno = as-urb-status;
sinfo.si_code = SI_ASYNCIO;
sinfo.si_addr = as-userurb;
- send_sig_info(as-signr, sinfo, as-task);
+ kill_proc_info_as_uid(as-signr, sinfo, as-pid, as-uid,
+ as-euid);
}
wake_up(ps-wait);
}
@@ -988,7 +992,9 @@ static int proc_do_submiturb(struct dev_
as-userbuffer = NULL;
as-signr = uurb-signr;
as-ifnum = ifnum;
- as-task = current;
+ as-pid = current-pid;
+ as-uid = current-uid;
+ as-euid = current-euid;
if (!(uurb-endpoint USB_DIR_IN)) {
if (copy_from_user(as-urb-transfer_buffer, uurb-buffer,
as-urb-transfer_buffer_length)) {
free_async(as);
diff --git a/include/linux/sched.h b/include/linux/sched.h
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1018,6 +1018,7 @@ extern int force_sig_info(int, struct si
extern int __kill_pg_info(int sig, struct siginfo *info, pid_t pgrp);
extern int kill_pg_info(int, struct siginfo *, pid_t);
extern int kill_proc_info(int, struct siginfo *, pid_t);
+extern int kill_proc_info_as_uid(int, struct siginfo *, pid_t, pid_t, pid_t);
extern void do_notify_parent(struct task_struct *, int
Re: [linux-usb-devel] Re: [Security] [vendor-sec] [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
);
@@ -1192,6 +1210,22 @@ kill_proc_info(int sig, struct siginfo *
return error;
}
+/* like kill_proc_info(), but doesn't use uid/euid of current */
+int
+kill_proc_info_as_uid(int sig, struct siginfo *info, pid_t pid,
+ pid_t uid, pid_t euid)
+{
+ int error;
+ struct task_struct *p;
+
+ read_lock(tasklist_lock);
+ p = find_task_by_pid(pid);
+ error = -ESRCH;
+ if (p)
+ error = group_send_sig_info_as_uid(sig, info, p, uid, euid);
+ read_unlock(tasklist_lock);
+ return error;
+}
/*
* kill_something_info() interprets pid in interesting ways just like kill(2).
@@ -2290,7 +2324,8 @@ asmlinkage long sys_tgkill(int tgid, int
p = find_task_by_pid(pid);
error = -ESRCH;
if (p (p-tgid == tgid)) {
- error = check_kill_permission(sig, info, p);
+ error = check_kill_permission(sig, info, p, current-uid,
+ current-euid);
/*
* The null signal is a permissions and process existence
* probe. No signal is actually delivered.
@@ -2330,7 +2365,8 @@ sys_tkill(int pid, int sig)
p = find_task_by_pid(pid);
error = -ESRCH;
if (p) {
- error = check_kill_permission(sig, info, p);
+ error = check_kill_permission(sig, info, p, current-uid,
+ current-euid);
/*
* The null signal is a permissions and process existence
* probe. No signal is actually delivered.
--
- Harald Welte [EMAIL PROTECTED] http://gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
pgpzqVID5nYav.pgp
Description: PGP signature
Re: [linux-usb-devel] Re: [Security] [vendor-sec] [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, Sep 27, 2005 at 10:02:16AM -0700, Linus Torvalds wrote: On Tue, 27 Sep 2005, Sergey Vlasov wrote: The initial patch added get_task_struct()/put_task_struct() calls to fix this - are they forbidden too? They are sure as hell not something that a _driver_ is supposed to use. It at least has sigio_perm(), which prevents exploiting it to send signals to tasks you don't have access to. And the point is, you can do that _too_. Do it right. Don't cache pointers to threads. Use the pid. So what happened to this thread? Was I simply removed from the Cc, or did the thread cease? Or is there a secret fix on vendor-sec? I'm probably the person in this thread who understands the least about the USB stack and the scheduler, but if there is no implementation of Linus' suggested PID approach yet, I'd be willing to write a patch and test it. Please let me know. Please also understand that I never argued that my initial patch was a good solution, or that I wanted it to have merged. I just wanted to show that there is a real-world problem, and it somehow needs to be fixed. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpiNwztz6nnG.pgp Description: PGP signature
[linux-usb-devel] [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
Hi! I've been working on some userspace usb drivers in which I use the asynchronous usb devio URB delivery to usrerspace. There have always been some bug reports of kernel oopses while terminating a program that uses the driver. Now I found out a way to relatively easy trigger that oops from pcscd (part of pcsc-lite) on any kernel, at least tested with 2.6.8 to 2.6.14-rc2. Call Trace: [c0103dbf] show_stack+0x7f/0xa0 [c0103f60] show_registers+0x160/0x1c0 [c0104156] die+0xf6/0x1a0 [c0112cd6] do_page_fault+0x356/0x68f [c01039bf] error_code+0x4f/0x54 [c0125fa9] send_sig_info+0x39/0x80 [c023cfd9] async_completed+0xa9/0xb0 [c0237e31] usb_hcd_giveback_urb+0x31/0x80 [f8a21e84] finish_urb+0x74/0x100 [ohci_hcd] [f8a22f88] finish_unlinks+0x2b8/0x2e0 [ohci_hcd] [f8a23d1d] ohci_irq+0x17d/0x190 [ohci_hcd] [c0237eb8] usb_hcd_irq+0x38/0x70 [c0139ab3] handle_IRQ_event+0x33/0x70 [c0139bcd] __do_IRQ+0xdd/0x150 [c010551c] do_IRQ+0x1c/0x30 [c010388a] common_interrupt+0x1a/0x20 So what do we learn from that? That usb_hcd_giveback_urb() is called from in_interrupt() context and calls async_completed(). async_completed() calls send_sig_info(), which in turn does a spin_lock(tasklist_lock) to protect itself from task_struct-sighand from going away. However, the call to spin_lock_irqsave(task_struct-sighand-siglock) causes an oops, because sighand has disappeared. If a process issues an URB from userspace and (starts to) terminate before the URB comes back, we run into the issue described above. This is because the urb saves a pointer to current when it is posted to the device, but there's no guarantee that this pointer is still valid afterwards. This basically means that any userspace process with permissions to any arbitrary USB device can Ooops any kernel.(!) In fact, there are two separate issues: 1) the pointer to current can become invalid, since the task could be completely gone when the URB completion comes back from the device. This can be fixed by get_task_struct() / put_task_struct(). 2) Even if the saved task pointer is still pointing to a valid task_struct, task_struct-sighand could have gone meanwhile. Therefore, the USB async URB completion handler needs to reliably check whether task_struct-sighand is still valid or not. In order to prevent a race with __exit_sighand(), it needs to grab a read_lock(tasklist_lock). This strategy seems to work, since the send_sig_info() code uses the same protection. However, we now need to export a __send_sig_info() function, one that expects to be called with read_lock(tasklist_lock) already held by the caller. It's ugly, but I doubt there is a less invasive solution. Expected FAQ's: a) Q: But grabbing references to current and delivering URB completion via signals is totally invalid and broken in may ways ! A: Yes, but dozens of userspace apps/drivers rely on this broken API. As long as there's no new, sane, usbdevio2, we cannot just rip it out without a replacement. b) Q: Why can't wa use the normal SIGIO mechanism? A: Because the usbdevio API needs to pass a __user pointer to the URB along the delivered signal. c) Q: If this is a local DoS, why did you post it publicly? A: Because I've already informed linux-usb-devel in May. I suggest this (or any other) fix to be applied to both 2.6.14 final and the stable series. I didn't yet investigate 2.4.x, but I think it is likely to have the same problem. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) [USBDEVIO] Fix user-triggerable Oops in usbdevio async URB completion If a process issues an URB from userspace and (starts to) terminate before the URB comes back, we run into the issue described above. This is because the urb saves a pointer to current when it is posted to the device, but there's no guarantee that this pointer is still valid afterwards. This basically means that any userspace process with permissions to any arbitrary USB device can Ooops any kernel.(!) In fact, there are two separate issues: 1) the pointer to current can become invalid, since the task could be completely gone when the URB completion comes back from the device. This can be fixed by get_task_struct() / put_task_struct(). 2) Even if the saved task pointer is still pointing to a valid task_struct, task_struct-sighand could have gone meanwhile. Therefore, the USB async URB completion handler needs to reliably check whether task_struct-sighand is still valid or not. In order to prevent a race with __exit_sighand(), it needs to grab a read_lock
Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
On Wed, Jun 01, 2005 at 12:12:58AM +0200, Harald Welte wrote: Wouldn't it help to associate the URB with the file (instaed of the task), and then send the signal to any task that still has opened the file? I'm willing to hack up a patch, if this is considered a sane fix. Sounds reasonable, except that not all such tasks will want the signal. Though I guess the infrastructure to filter the signal out already exists, so the main missing piece is that urb-to-file binding. Ok, I'll get something coded shortly. Unfortunately this approach is not feasible, since there is no 'reverse mapping' from a file to a process. So for every URB delivery, we would have to walk that task_list and check which tasks have opened this file. So what do we do now? A reimplementation of async URB handling (probably use the AIO code) from userspace is a significant amount of work. Meanwhile, this bug allows any regular non-root userspace program with access to a single USB device to oops the kernel, so a short-term fix is definitely required for security reasons. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpCgdcQePmVa.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
On Mon, Jun 06, 2005 at 12:24:25PM -0400, Alan Stern wrote: Ok, I'll get something coded shortly. Unfortunately this approach is not feasible, since there is no 'reverse mapping' from a file to a process. So for every URB delivery, we would have to walk that task_list and check which tasks have opened this file. What about something like the standard FSETOWN fnctl? I investigated this option, too. The magic behind FSETOWN doesn't allow us to pass the URB address back to the process (together with the signal). -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpyZf6aSRNCX.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
On Tue, May 31, 2005 at 01:09:06AM +0200, Oliver Neukum wrote: Am Dienstag, 31. Mai 2005 00:55 schrieb David Brownell: The logic closing an open usbfs file -- which is done before any task exits with such an open file -- is supposed to block till all its URBs complete. So the pointer to the task should be valid for as long as any URB it's submitted is active. What happens if you pass such an fd through a socket? which is exactly what happens on certain distributions for all device opens if you look at SuSE's recent (in?)famous invention of resmgrd) -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgp3aNMFTUSH0.pgp Description: PGP signature
[linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
On Tue, May 31, 2005 at 01:07:03AM +0200, Oliver Neukum wrote: and it prints p-sighand == NULL every time I exit a program while using the usbdevio based driver. consequently, the following patch 'fixed' the problem. Please do not consider this as a real fix, since there's certainly still a race condition left. Please use it as a hint to correctly fix the problem. It would be cleaner to terminate all URBs a task has submitted when the task terminates. so for every task termination, we do a linear search over the global list of pending URB's and terminate those where urb-task == taks_to_kill? Sounds a bit expensive, especially since you don't know (before iteration) whether that task has actually ever dealt with usbdevio or not. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpo6N3TpAvN9.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
On Mon, May 30, 2005 at 03:55:39PM -0700, David Brownell wrote:
The logic closing an open usbfs file -- which is done before any task
exits with such an open file -- is supposed to block till all its URBs
complete. So the pointer to the task should be valid for as long as
any URB it's submitted is active.
unfortunately it doesn't seem to cover the fork() case, see below.
I'm not familiar with the scheduler code to decide what fix
is the way to go. Is it sufficient to do {get,put}_task_struct() from
the usb code?
It's worth making that change in any case, to avoid such questions in
the future. And if it does any good, more power to the patch!
Ok.
Not that it helps at all, but I've never really trusted the usbfs async
I/O code. Real AIO could be a lot more obviously correct. And smaller.
mh, but nobody has written AIO-enabled usbfs2 yet ;)
meanwhile, the current usbfs aio handling is the only way how to deal
with delivery of interrupt pipe URB's to userspace drivers.
mh. it appears like it's sighand which disappears, not the task itself.
...
Odd. Isn't that nulled only in __exit_sighand(), which gets called only
when the task itself is finally being freed?
yes, I couldn't find any other location but __exit_sighand() that nulls
task-sighand. And looking at exit.c, do_exit() definitely calls
__exit_files(tsk) before it calls __exit_sighand() via exit_notify().
However, __exit_files() only calls close_files() if files-count goes
down to zero. What if the process fork()ed before, and the other half of
the fork still has a refcount? - boom.
It seems to me that the whole usbdevio async handling doesn't really
cope with a lot of the unix semantics, such as fork() or file descriptor
passing.
Wouldn't it help to associate the URB with the file (instaed of the
task), and then send the signal to any task that still has opened the
file? I'm willing to hack up a patch, if this is considered a sane fix.
Cheers,
Harald
--
- Harald Welte [EMAIL PROTECTED] http://gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
pgp3eeHFmY3OA.pgp
Description: PGP signature
Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
On Tue, May 31, 2005 at 11:53:24AM -0700, David Brownell wrote: I'm still hoping that one of the folk who want make an interesting and useful contribution to Linux will take the hint. It goes slowly. :) I've pondered about three times whether to start or not. I'd rather not, since I'm already having problems keeping up with all my other projects :( meanwhile, the current usbfs aio handling is the only way how to deal with delivery of interrupt pipe URB's to userspace drivers. Other than tying up the file descriptor with a blocking read, that is. you're probably using that same file descriptor for reading/writing from/to bulk endpoints at the same time. I don't see how a 'blocking read' would help. Wouldn't it help to associate the URB with the file (instaed of the task), and then send the signal to any task that still has opened the file? I'm willing to hack up a patch, if this is considered a sane fix. Sounds reasonable, except that not all such tasks will want the signal. Though I guess the infrastructure to filter the signal out already exists, so the main missing piece is that urb-to-file binding. Ok, I'll get something coded shortly. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpa23CcYuLPZ.pgp Description: PGP signature
[linux-usb-devel] [BUG] oops while completing async USB via usbdevio
to
spin_lock_irqsave(task_struct-sighand-siglock) causes an oops. So
either sighand or the task have disappeared.
I think there is currently no protection/locking/refcounting going on.
If a process issues an URB from userspace and starts to terminate before
the URB comes back, we run into the issue described above. This is
because the urb saves a pointer to current when it is posted to the
device, but there's no guarantee that this pointer is still valid
afterwards.
I'm not familiar with the scheduler code to decide what fix
is the way to go. Is it sufficient to do {get,put}_task_struct() from
the usb code?
Any comments welcome...
--
- Harald Welte [EMAIL PROTECTED] http://gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
pgp9G2EJtmnh3.pgp
Description: PGP signature
[linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
On Mon, May 30, 2005 at 09:44:44PM +0200, Harald Welte wrote:
I think there is currently no protection/locking/refcounting going on.
If a process issues an URB from userspace and starts to terminate before
the URB comes back, we run into the issue described above. This is
because the urb saves a pointer to current when it is posted to the
device, but there's no guarantee that this pointer is still valid
afterwards.
I'm not familiar with the scheduler code to decide what fix
is the way to go. Is it sufficient to do {get,put}_task_struct() from
the usb code?
mh. it appears like it's sighand which disappears, not the task itself.
I've tried the following patch:
Index: linux-2.6.12-rc5/kernel/signal.c
===
--- linux-2.6.12-rc5.orig/kernel/signal.c 2005-05-30 18:23:55.0
+0200
+++ linux-2.6.12-rc5/kernel/signal.c2005-05-30 23:20:49.0 +0200
@@ -1258,6 +1258,15 @@
if (!valid_signal(sig))
return -EINVAL;
+ if (!p) {
+ printk(%s p == NULL\n);
+ return -EINVAL;
+ }
+ if (!p-sighand) {
+ printk(%s:%u p-sighand == NULL\n, __FUNCTION__, p-pid);
+ return -EINVAL;
+ }
+
/*
* We need the tasklist lock even for the specific
* thread case (when we don't need to follow the group
and it prints p-sighand == NULL every time I exit a program while
using the usbdevio based driver.
consequently, the following patch 'fixed' the problem. Please do not
consider this as a real fix, since there's certainly still a race
condition left. Please use it as a hint to correctly fix the problem.
Index: linux-2.6.12-rc5/drivers/usb/core/devio.c
===
--- linux-2.6.12-rc5.orig/drivers/usb/core/devio.c 2005-05-26
15:49:57.0 +0200
+++ linux-2.6.12-rc5/drivers/usb/core/devio.c 2005-05-30 23:21:06.0
+0200
@@ -283,7 +283,8 @@
sinfo.si_errno = as-urb-status;
sinfo.si_code = SI_ASYNCIO;
sinfo.si_addr = as-userurb;
- send_sig_info(as-signr, sinfo, as-task);
+ if (as-task as-task-sighand)
+ send_sig_info(as-signr, sinfo, as-task);
}
wake_up(ps-wait);
}
Thanks,
--
- Harald Welte [EMAIL PROTECTED] http://gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
pgpfZMmqeGJ5O.pgp
Description: PGP signature
[linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?
Hi! I've been playing quite a bit with the gnuradio[1] project's USRP[2] recently. One of the key issues with the USRP is to get the highes possible USB2.0 throughput (since the ADC and DAC's actually outperform the slow USB2.0 bus). Another key issue is that for digital signal processing you need lots of CPU. since gnuradio uses usbdevfs and libusb in order to rx and tx data to the USRP, it copies all data back and forth between kernel and userspace. Obviously, this kind of high-bandwith USB use is usually only seen from kernel drivers (mass storage, ...) whereas libusb+usbdevfs is only used for lower bandwith applications. So there is room for improvements... Having a networking background, I thought this is similar to the network stack and mmap()ed PF_PACKET (and now even PF_RING) sockets. A quick browse through the EHCI specification and the ehci linux hcd driver revealed that it should be technically possible to: 0) open an usbdevfs file like usual 1) set up a mmap()ed buffer between kernel and userspace 2) create one (or multiple consecutive) urb that points into the mmap()ed buffer 3) submit that urb to ehci-hcd, which would in turn set up qtd's pointing directly into that buffer The result should be a truly zerocopy dma-to-userspace architecture. As my only connection with the usb code so far has been the cyberjack driver and usbdevfs- based userspace programs, I'd like to receive the comments of people more familiar with the usb subsystem. Do you think a system described above is actually feasible? If yes, what kind of implementation suggestions do you have? [1] http://comsec.com/wiki [2] http://comsec.com/wiki?UniversalSoftwareRadioPeripheral -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpqDDCqYOSfS.pgp Description: PGP signature
[linux-usb-devel] [PATCH 2.6] maintainers / documentation update cyberjack
Here's a pure documentation update for the cyberjack driver. Please apply at your convenience, thanks. -- - Harald Welte [EMAIL PROTECTED] http://www.hmw-consulting.de/ = Consultant for linux networking, network security, linux driver development --- c/MAINTAINERS 2005-02-13 13:51:51.0 +0100 +++ d/MAINTAINERS 2005-02-15 00:45:40.359214264 +0100 @@ -2376,6 +2376,12 @@ W: http://www.chello.nl/~j.vreeken/se401/ S: Maintained +USB SERIAL CYBERJACK DRIVER +P: Matthias Bruestle and Harald Welte +M: [EMAIL PROTECTED] +W: http://www.reiner-sct.de/support/treiber_cyberjack.php +S: Maintained + USB SERIAL DIGI ACCELEPORT DRIVER P: Peter Berger and Al Borchers M: [EMAIL PROTECTED] --- c/drivers/usb/serial/cyberjack.c2004-12-24 22:35:28.0 +0100 +++ d/drivers/usb/serial/cyberjack.c2005-02-15 00:47:46.991963160 +0100 @@ -4,7 +4,7 @@ * Copyright (C) 2001 REINER SCT * Author: Matthias Bruestle * - * Contact: [EMAIL PROTECTED] (see MAINTAINERS) + * Contact: [EMAIL PROTECTED] (see MAINTAINERS) * * This program is largely derived from work by the linux-usb group * and associated source files. Please see the usb/serial files for @@ -20,6 +20,11 @@ * * In case of problems, please write to the contact e-mail address * mentioned above. + * + * Please note that later models of the cyberjack reader family are + * supported by a libusb-based userspace device driver. + * + * Homepage: http://www.reiner-sct.de/support/treiber_cyberjack.php#linux */
[linux-usb-devel] Re: USBmon
On Mon, Dec 13, 2004 at 08:49:22PM -0800, Pete Zaitcev wrote: Hi, Harald: Back in June you mentioned that you use USBmon. I am thinking about giving this a second look. Where did you get the userland to drive it? There's no apparent link off linux-usb.org. you don't actually need any userland, you can just cat the contents of the respective files. It's ascii output. Thanks, -- Pete -- - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Programming is like sex: One mistake and you have to support it your lifetime signature.asc Description: Digital signature
Re: [linux-usb-devel] usbfs2 ... what should be in it?
On Tue, Jun 15, 2004 at 03:29:10PM -0700, Johannes Erdfelt wrote: * How should this relate to udev? One implementation strategy would make usbfs2 endpoint files be regular character devices. There are other strategies too, including not coupling them at all. Perhaps a sockets interface would be more appropriate? From my point of view, a socket interface would definitely resemble USB better. After all, it is a packet oriented bus, and you have different devices with adresses. You also have well-understood semantics of 'binding' to an address, including a failure to bind if the address is already in use. But maybe that's just my strange view on the world as coming from a strong networking background. As already discovered in a recent thread here, USB snooping is very analogous to what tcpdump [or other pcap based software] dpes. The socket level could then determine whether you're intereted in sniffing/sending raw usb packets at the HCD (RAW usb socket) or whether you're interested in communicating with a specific device/interface/endpoint. JE -- - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Programming is like sex: One mistake and you have to support it your lifetime signature.asc Description: Digital signature
Re: [linux-usb-devel] [PATCH] USB fixes for 2.6.7-rc3
On Wed, Jun 16, 2004 at 11:17:10AM +0200, Harald Welte wrote: Apparently interface-dev is 0x10 here, thus usb_get_drvdata() inlined by get_intfdata() dereferences 0x10+0x74 == 0x84 After some more debugging, it becomes obvious that usb_serial_disconnect() is called twice. First: usb_serial_deregister() usb_serial_disconnect() kref_put() usb_set_intfdata(interface, NULL) [kref destrructor] destroy_serial() serial_shutdown() cyberjack_shutdown() return_serial() [?] port_release() ... then, again [from where???]: usb_serial_disconnect() [see attached usb debug-enabed dmesg output. First it shows the output captured while rmmod of a device that hasn't been used at all (plug-rmmod). second part: plug-use-rmmod]. Any ideas? -- - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Programming is like sex: One mistake and you have to support it your lifetime good: usb 1-2.3: USB disconnect, address 4 drivers/usb/serial/usb-serial.c: usb_serial_disconnect serial=ef768258, serial-kref=ef768294, serial-kref-refcnt=1 drivers/usb/serial/usb-serial.c: destroy_serial - Reiner SCT Cyberjack USB card reader drivers/usb/serial/usb-serial.c: serial_shutdown drivers/usb/serial/cyberjack.c: cyberjack_shutdown drivers/usb/serial/usb-serial.c: return_serial cyberjack ttyUSB0: Reiner SCT Cyberjack USB card reader converter now disconnected from ttyUSB0 drivers/usb/serial/usb-serial.c: port_release - ttyUSB0 cyberjack 1-2.3:1.0: device disconnected bad: usbcore: deregistering driver cyberjack drivers/usb/serial/usb-serial.c: USB Serial deregistering driver Reiner SCT Cyberjack USB card reader drivers/usb/serial/usb-serial.c: usb_serial_disconnect serial=ef004438, serial-kref=ef004474, serial-kref-refcnt=1 drivers/usb/serial/usb-serial.c: destroy_serial - Reiner SCT Cyberjack USB card reader drivers/usb/serial/usb-serial.c: serial_shutdown drivers/usb/serial/cyberjack.c: cyberjack_shutdown drivers/usb/serial/usb-serial.c: return_serial cyberjack ttyUSB0: Reiner SCT Cyberjack USB card reader converter now disconnected from ttyUSB0 drivers/usb/serial/usb-serial.c: port_release - ttyUSB0 usbserial 1-2.3:1.0: device disconnected drivers/usb/serial/usb-serial.c: usb_serial_disconnect Unable to handle kernel NULL pointer dereference at virtual address = serial_disconnect called twice. signature.asc Description: Digital signature
Re: [linux-usb-devel] [PATCH] USB fixes for 2.6.7-rc3
On Wed, Jun 16, 2004 at 10:58:00AM -0700, Greg KH wrote: [see attached usb debug-enabed dmesg output. First it shows the output captured while rmmod of a device that hasn't been used at all (plug-rmmod). second part: plug-use-rmmod]. Ick, that's not good. Exactly what sequence of steps did you do to achive it? [host controller driver: uhci_hcd] - plug in the device, have the driver hotplug-loaded - start 'cjgeldkarte' - have 'cjgeldkarte' terminate - unplug the device thanks, greg k-h -- - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Programming is like sex: One mistake and you have to support it your lifetime signature.asc Description: Digital signature
[linux-usb-devel] USBMon for kernel 2.4.20
Hi Dave (and all linux usb developers)
I just ported/merged your USBMon for linux 2.4.4 into the 2.4.20 kernel.
You might be interested in making this available to other users, patch
is attached.
Since I'm currently debugging some issues while developing a USB driver,
it is likely that I'll port/merge USBMon for 2.4.26 and 2.6.6 during the
next week, too.
--
- Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/
Programming is like sex: One mistake and you have to support it your lifetime
diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru
linux-2.4.20-cjtest/drivers/usb/devio.c linux-2.4.20-cjtest-usbmon/drivers/usb/devio.c
--- linux-2.4.20-cjtest/drivers/usb/devio.c 2002-11-29 00:53:14.0 +0100
+++ linux-2.4.20-cjtest-usbmon/drivers/usb/devio.c 2004-06-04 15:30:19.0
+0200
@@ -43,6 +43,7 @@
#include linux/usb.h
#include linux/usbdevice_fs.h
#include asm/uaccess.h
+#include linux/time.h /*for USBMon*/
struct async {
@@ -57,6 +58,7 @@
static loff_t usbdev_lseek(struct file *file, loff_t offset, int orig)
{
+ printk(usbdev_lseek called.\n);
switch (orig) {
case 0:
file-f_pos = offset;
@@ -1238,3 +1240,430 @@
open: usbdev_open,
release:usbdev_release,
};
+
+
+/*** USBMon Addition */
+
+
+static int usbmon_open(struct inode *inode, struct file *file)
+{
+ struct usb_device *dev;
+ int ret;
+
+ printk([USBMon] usbmon_open called with inode=%p\n,inode);
+
+ lock_kernel();
+ ret = -ENOENT;
+ if (ITYPE(inode-i_ino) != IDEVICEMON)
+ goto out;
+ dev = inode-u.usbdev_i.p.dev;
+ if (!dev)
+ goto out;
+
+ ret = 0;
+
+ dev-USBMon_data-USBMon_urb_ll_buffered =
+ dev-USBMon_data-USBMon_urb_ll_head;
+ wmb();
+ dev-USBMon_data-USBMon_urb_ll_head = NULL;
+ wmb();
+ dev-USBMon_data-USBMon_urb_ll_last = NULL;
+ wmb();
+
+ file-private_data = dev;
+ out:
+ unlock_kernel();
+return ret;
+}
+
+static int usbmon_release(struct inode *inode, struct file *file)
+{
+ struct urb *temp_urb1, *temp_urb2;
+ struct usb_device *dev;
+
+ dev = (struct usb_device *)(file-private_data);
+
+ temp_urb1=dev-USBMon_data-USBMon_urb_ll_buffered;
+
+ wmb();
+
+ dev-USBMon_data-USBMon_urb_ll_buffered=NULL;
+
+
+ while(temp_urb1 != NULL){
+ temp_urb2 = temp_urb1;
+ if(temp_urb1-transfer_buffer){
+ kfree(temp_urb1-transfer_buffer);
+ }
+ temp_urb1=temp_urb1-next;
+ kfree(temp_urb2);
+ }
+return 0;
+}
+
+static ssize_t usbmon_read(struct file *file, char * buf, size_t nbytes, loff_t *ppos)
+{
+ ssize_t ret = 0;
+ unsigned int len=0;
+ unsigned int already_copied=0;
+ unsigned int skipped=0;
+ int i;
+ loff_t pos;
+ char a[5120];
+ struct usb_device *dev;
+ struct urb *purb;
+ int finished=0;
+
+ pos = *ppos;
+
+ if (!file-private_data) {
+ ret = -ENODEV;
+ goto err;
+ } else if (pos 0) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ dev=(struct usb_device *)file-private_data;
+
+ printk([USBMon] read on device %d, buffered=%8p\n,
+ dev-devnum,
+ dev-USBMon_data-USBMon_urb_ll_buffered);
+
+ purb = dev-USBMon_data-USBMon_urb_ll_buffered;
+
+ if(purb == NULL){
+ finished=1;
+ }
+ while(finished == 0){
+ {
+ int dp=0, al=0;
+ if(purb-transfer_buffer == NULL){
+ dp=0;
+ }else{
+ dp=1;
+ }
+ sprintf(a,[URB completed on Device=%03d,
+ Endpoint=%02d, Pipe=%08X,
+ status= % 03d, size= %08d, transfer_flags =
+ %08X, actual_length = %08d,
+ error count = %05d completion_time = %02ld
+ :%02ld:%02ld:%06ld dp=%d data=,
+ purb-dev-devnum,
+ (purb-pipe (0xf 15))15,
+ purb-pipe,
+ purb-status,
+ purb-transfer_buffer_length,
+ purb-transfer_flags,
+ purb-actual_length,
+ purb-error_count
Re: [linux-usb-devel] USBMon for kernel 2.4.20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jun 04, 2004 at 07:45:48AM -0700, Pete Zaitcev wrote: On Fri, 4 Jun 2004 16:23:19 +0200 Harald Welte [EMAIL PROTECTED] wrote: + dev = (struct usb_device *)(file-private_data); + + temp_urb1=dev-USBMon_data-USBMon_urb_ll_buffered; + + wmb(); + + dev-USBMon_data-USBMon_urb_ll_buffered=NULL; You need more semaphores and less monkeying with barriers. This is not my code, I just merged Dave Hardings 2.4.4 patch with a more recent 2.4.x kernel. I don't intend to become the maintainer of USBMon ;) @@ -2105,6 +2113,7 @@ usb_dec_dev_use (usb_dev); urb-dev = NULL; if (urb-complete) + USBMon_urb_pre_completion(urb);/*USBMon*/ urb-complete (urb); return 0; What do you think the above does? No, really? erm, sorry once again... bug was already present in the original code to be found at http://www.linux-usb.org/USBMon/. I will fix it in my local tree, though. Something has to be said about the atrocious styling as well. yes, I dislike it, too. But as I'm not the original author and just touched somebody else's code - I don't think I should change the overall CodingStyle if I want that patch to get accepted by Dave Harding. -- Pete To be frank, I'm not sure whether I agree with the overall architecture of USBMon, let aside it's coding style. But AFAIK it is the only freely available usb sniffer available for Linux, and that's why I'm using it. Thanks for your comments, - -- - - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Programming is like sex: One mistake and you have to support it your lifetime -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAwJ5VXaXGVTD0i/8RAgzZAJ9zDPCNdvaq9UKDp+DelBJOKUIQagCeLEel mV9NgGEdAHlShZtHSQbkI2s= =/Sou -END PGP SIGNATURE- --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USBMon for kernel 2.4.20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jun 04, 2004 at 09:54:46AM -0700, Greg KH wrote: On Fri, Jun 04, 2004 at 06:07:49PM +0200, Harald Welte wrote: yes, I dislike it, too. But as I'm not the original author and just touched somebody else's code - I don't think I should change the overall CodingStyle if I want that patch to get accepted by Dave Harding. You should fix it if you want the patch to be accepted into the kernel tree :) oh no, I didn't submit this for kernel inclusion. I just posted it to the list in case somebody else was interested. But AFAIK it is the only freely available usb sniffer available for Linux, and that's why I'm using it. Hm, I started to add such a functionality to the usbfs code. Right now it logs any usbfs control urbs and basic what did the user just ask to do type messages. See the latest 2.6 kernel for it. You might want to start with that code and extend it to encompass the remaining usbfs calls. but that would only work for libusb or other userspace usb drivers. In my case, it's actually a kernel driver (cyberjack, working together with REINER SCT and the original Author Matthias Bruestle) I want to debug... thanks, greg k-h - -- - - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Programming is like sex: One mistake and you have to support it your lifetime -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAwLPpXaXGVTD0i/8RAq6WAKCz7EfjpmFc6eG4/eDAgUEJldWBbgCfbA1I B4N8ZZYU2NZaiRY8XKhq3vc= =7z5j -END PGP SIGNATURE- --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
