[linux-usb-devel] Help on OTG driver architecture
Hi all, As there is not too much document and reference code available around, I have some confusion regarding OTG driver architecture in Linux. Here is my understanding. Please correct me if I am wrong, and more clarification is appreciated. There will be three separate drivers: host, client, otg transceiver (for ULPI system not a really transceiver driver). User chooses what functions to use by configure kernel or selectively insert modules. If user only load host/gadget driver, the board will act as solely host/device. If the otg driver is loaded, each host/gadget driver will register themselves to the otg driver. Otg driver will use suspend() function to set both controller drivers to stop state until otg driver determines which driver to take control. OTG state machine will be maintained and accessible in otg driver only, and otg driver will use standard xhci/gadget operations to control host/client through state changes. Assume there is a role change. For device mode, it initializes hardware and waits for reset. For host mode, how to trigger reset and enumeration? If the host/client/otg use only one interrupt, should it be processed with shared irq or centralized in otg driver and designate to special handler? -- Leo Li Freescale Semiconductor [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Help on OTG driver architecture
--- Li Yang-r58472 [EMAIL PROTECTED] wrote: Hi all, As there is not too much document and reference code available around, I have some confusion regarding OTG driver architecture in Linux. Here is my understanding. Please correct me if I am wrong, and more clarification is appreciated. Try this: http://www.linux-usb.org/gadget/h2-otg.html ---Komal Shah http://komalshah.blogspot.com/ __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] RFC drivers/usb/storage/libusual
On Wed, 2005-09-28 at 17:01 -0700, Pete Zaitcev wrote: - request_module() is icky. I keep wanting to get rid of that function, and really don't want to see any further users get added. But that's just my feeling, if there's no other way to do this, I don't mind. Yes, yes, and yes. And also, it looks to me as if I am trying to do something which obviously belongs to modprobe or other user mode component. The trouble is, I am unable to find a different solution which would not involve an alias pointing to an alias, and Rusty's modprobe does not allow that. I could hack it up easily, but he put in a comment, that way lies madness. He probably knew what he was doing. I just didn't want to do loop detection. In userspace you can use an install command to get the same effect. Now, why did we want this? In small words... Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Help on OTG driver architecture
There will be three separate drivers: host, client, otg transceiver (for ULPI system not a really transceiver driver). Rather than transceiver driver, I'd say OTG driver ... the thing responsible for role detection and switching. So for drivers that touch hardware, (a) OTG driver, (b) HCD, and (c) peripheral controller drivers. Plus (d) a gadget driver, talking to a host through that peripheral controller driver, and (e) two or more usb device drivers on the host side, including the hub driver. (You need to support at least root hubs. OTG of course doesn't require supporting external hubs, but for EHCI or OHCI there'd be no point in trying to remove that capability.) User chooses what functions to use by configure kernel or selectively insert modules. If user only load host/gadget driver, the board will act as solely host/device. Actually there is CONFIG_USB_OTG which is needed to enable OTG behavior during host-side enumeration, like updating peripheral HNP state. And when OTG is enabled, the OTG driver had better do _nothing_ until both host and peripheral drivers are fully active ... you could use hotplug to load the (e) host side drivers, but not the (d) gadget driver unless you can somehow guarantee it modprobes quickly enough to meet the enumeration timing constraints. If the otg driver is loaded, each host/gadget driver will register themselves to the otg driver. Otg driver will use suspend() function to set both controller drivers to stop state until otg driver determines which driver to take control. Using suspend() is probably not going to work as well as it should because of the general lack of runtime PM support in Linux. I'd certainly expect the (b) HCD and (c) peripheral controller drivers to stay inactive until they're needed, but just how that's arranged could be up to some private agreement between those collaborating drivers. OTG state machine will be maintained and accessible in otg driver only, and otg driver will use standard xhci/gadget operations to control host/client through state changes. No, the OTG states are visible outside the OTG driver. See for example the HNP state flags in usb_bus and usb_gadget. And it's usbcore that causes those state flags to change. The specific state may not be represented outside that OTG driver though. Assume there is a role change. For device mode, it initializes hardware and waits for reset. For host mode, how to trigger reset and enumeration? By role change you must mean HNP, since the other cases are nothing more than normal enumeration. (With OTG driver sensing the state of the ID pin, using it to activate the right driver.) HNP is initiated by the host, when it suspends the device after HNP has been enabled. Maybe because the peripheral isn't on the list of supported devices, or maybe it's just done using the peripheral. If the host/client/otg use only one interrupt, should it be processed with shared irq or centralized in otg driver and designate to special handler? That's an implementation-specific choice. Do what's most natural. - Dave --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] 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
---
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 Mon, 2005-10-10 at 11:07 -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. Just mark it DEPRECATED since it basically is that?! Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Question on usage of urb-hcpriv field.
Alan 2005/10/10, Alan Stern [EMAIL PROTECTED]: The only way it can happen is if your HCD set urb-hcpriv to NULL earlier, or never set it to a non-NULL value. It must be a bug in the HCD. still tracking my bug...I just have 2 questions, I looked at uhci hcd to have an idea on how interrupts and locks must be handled in hcd-urb_enqueue method. uhci hcd simply disables IT in this method, so every allocations are atomic and mem_flags parameters is simply discarded. Furthermore it doesn't held urb-lock when using urb-status field for example. Are these 2 points are correct ? Can I do the same in my hcd ? Thanks -- Franck --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Question on usage of urb-hcpriv field.
On Tue, 11 Oct 2005, Franck wrote: still tracking my bug...I just have 2 questions, I looked at uhci hcd to have an idea on how interrupts and locks must be handled in hcd-urb_enqueue method. uhci hcd simply disables IT in this method, so every allocations are atomic and mem_flags parameters is simply discarded. That's right. Furthermore it doesn't held urb-lock when using urb-status field for example. Be more careful here. It doesn't hold urb-lock while _reading_ urb-status; there's no point. But it does hold urb-lock while _writing_ urb-status. That is necessary. Are these 2 points are correct ? Can I do the same in my hcd ? Subject to the restriction about writing urb-status, yes. Alan Stern --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Question on usage of urb-hcpriv field.
2005/10/11, Alan Stern [EMAIL PROTECTED]: Be more careful here. It doesn't hold urb-lock while _reading_ urb-status; there's no point. But it does hold urb-lock while _writing_ urb-status. That is necessary. hmm, sorry but I don't see why it needs a lock while writing but not while reading...can you explain please ? Another point in my hcd is that an urb can already be transfered by hw before hcd-urb_enqueue method is called. Actually as soon as this urb is linked into the corresponding ep's urb list, the hw can send it. Do you think it can be an issue ? I'm asking this question because I get sometime a warning on the console saying: Badness in kref_get at lib/kref.c:32. Thanks -- Franck --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Question on usage of urb-hcpriv field.
On Tue, 11 Oct 2005, Franck wrote: 2005/10/11, Alan Stern [EMAIL PROTECTED]: Be more careful here. It doesn't hold urb-lock while _reading_ urb-status; there's no point. But it does hold urb-lock while _writing_ urb-status. That is necessary. hmm, sorry but I don't see why it needs a lock while writing but not while reading...can you explain please ? This is true of shared values in general. The purpose of a lock is to let you do something, knowing that the value won't change while you're doing it. If all you're doing is reading, then it usually doesn't matter whether the value changes. Consider a simple example of reading: spin_lock(urb-lock); if (urb-status == -EINPROGRESS) printk(URB is in progress\n); else printk(URB is not in progress\n); spni_unlock(urb-lock); Now imagine what would happen if the code didn't acquire the lock. The value could be changed by another thread in between the if statement's test and the printk statement. But who cares? The overall effect is exactly the same as if the other thread had changed the value _after_ the printk statement executed. Okay, so consider an example of writing: spin_lock(urb-lock); if (urb-status == -EINPROGRESS) urb-status = 0; spin_unlock(urb-lock); Now imagine what could happen if the code didn't acquire the lock. Another thread could unlink the URB, changing urb-status to -ENOENT, in between the if statement's test and the assignment statement. This would mean the code would do something very wrong: It would set the unlinked URB's status to 0. Another point in my hcd is that an urb can already be transfered by hw before hcd-urb_enqueue method is called. Actually as soon as this urb is linked into the corresponding ep's urb list, the hw can send it. Do you think it can be an issue ? Yes. Your code does not own the ep's list, usbcore does. Your HCD should not even be aware of an URB until urb_enqueue is called. You need to maintain your own lists, using the urb-hcpriv private data structure. What would happen if your urb_enqueue method had to reject the submission because it couldn't allocate memory for the private data structure? The hardware might already be transferring the rejected URB! I'm asking this question because I get sometime a warning on the console saying: Badness in kref_get at lib/kref.c:32. Without knowing more about the context, I can't say what that error message is related to. Alan Stern --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
Alan asked: But why do people go to the effort of confusing readers by using ^ instead of !=? My guess - eor (^) was quicker than not-equal (!=) on a PDP-11. That code fragment for checking uid's has been around a -long- time, if my memory serves me. It's gotten to be like the infamous !! boolean conversion operator, a bit of vernacular that would be harder to read if recoded using modern coding style. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, 11 Oct 2005, Paul Jackson wrote:
Alan asked:
But why do people go to the
effort of confusing readers by using ^ instead of !=?
My guess - eor (^) was quicker than not-equal (!=) on a PDP-11.
That code fragment for checking uid's has been around a -long-
time, if my memory serves me.
It's gotten to be like the infamous !! boolean conversion
operator, a bit of vernacular that would be harder to read if
recoded using modern coding style.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
Also, at one time, people used to spend a lot of time
minimizing the number of CPU cycles used in the code.
For instance, when it's appropriate, using XOR makes the
resulting generated code simpler and usually faster:
int funct0(int i)
{
return i ^ 1;
}
int funct1(int i)
{
return (i != 1);
}
int main()
{
int i;
for(i=0; i 100; i++)
{
if(funct0(i))
printf(Yep %d\n, i);
if(funct1(i))
printf(Yep %d\n, i);
}
return 0;
}
gcc -O2 -fomit-frame-pointer ...
Here, funct0 clearly uses less code.
Disassembly of section .text:
funct0:
0: 8b 44 24 04 mov0x4(%esp),%eax
4: 83 f0 01xor$0x1,%eax
7: c3 ret
0008 funct1:
8: 31 c0 xor%eax,%eax
a: 83 7c 24 04 01 cmpl $0x1,0x4(%esp)
f: 0f 95 c0setne %al
12: c3 ret
13: 90 nop
0014 main:
[SNIPPED...]
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.44 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
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] Question on usage of urb-hcpriv field.
2005/10/11, Alan Stern [EMAIL PROTECTED]: On Tue, 11 Oct 2005, Franck wrote: 2005/10/11, Alan Stern [EMAIL PROTECTED]: Be more careful here. It doesn't hold urb-lock while _reading_ urb-status; there's no point. But it does hold urb-lock while _writing_ urb-status. That is necessary. hmm, sorry but I don't see why it needs a lock while writing but not while reading...can you explain please ? This is true of shared values in general. The purpose of a lock is to let you do something, knowing that the value won't change while you're doing it. If all you're doing is reading, then it usually doesn't matter whether the value changes. Consider a simple example of reading: spin_lock(urb-lock); if (urb-status == -EINPROGRESS) printk(URB is in progress\n); else printk(URB is not in progress\n); spni_unlock(urb-lock); Now imagine what would happen if the code didn't acquire the lock. The value could be changed by another thread in between the if statement's test and the printk statement. But who cares? The overall effect is exactly the same as if the other thread had changed the value _after_ the printk statement executed. hmm, this example may be correct not because you're _reading_ the value but because printk statement doesn't _use_ urb's data structure. Another point in my hcd is that an urb can already be transfered by hw before hcd-urb_enqueue method is called. Actually as soon as this urb is linked into the corresponding ep's urb list, the hw can send it. Do you think it can be an issue ? Yes. Your code does not own the ep's list, usbcore does. Your HCD should not even be aware of an URB until urb_enqueue is called. You need to maintain your own lists, using the urb-hcpriv private data structure. Well, I have my own lists of active ep (actually it's the same mechanism as sl811-hcd driver by David Brownell). Each active ep have a reference to its associated usbcore ep. It allows to retrieve list of URB for that ep. What would happen if your urb_enqueue method had to reject the submission because it couldn't allocate memory for the private data structure? The hardware might already be transferring the rejected URB! In that case it can't happen. Allocation happens only when scheduling an ep the first time. At this time this ep in not in my list of active ep so it's not a candidate for transfering URB. If you want to take a look to this hcd, I can send it to you. Your comments are _very_ welcome. Thanks. -- Franck --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, 11 Oct 2005, linux-os (Dick Johnson) wrote: On Tue, 11 Oct 2005, Paul Jackson wrote: Alan asked: But why do people go to the effort of confusing readers by using ^ instead of !=? My guess - eor (^) was quicker than not-equal (!=) on a PDP-11. That code fragment for checking uid's has been around a -long- time, if my memory serves me. It's gotten to be like the infamous !! boolean conversion operator, a bit of vernacular that would be harder to read if recoded using modern coding style. Surely Linux uses entirely original code, with no hangovers from the original ATT Unix... Besides, to the best of my recollection, the two operations are equal in speed on a PDP-11. !! makes sense as an idiom. But ^ for != doesn't, at least not in this context. Also, at one time, people used to spend a lot of time minimizing the number of CPU cycles used in the code. For instance, when it's appropriate, using XOR makes the resulting generated code simpler and usually faster: ... Yes, sometimes XOR can yield simpler object code. But not in cases like this, where it's part of a Boolean test: if (... (a1^b1) (a2^b2) (a3^b3)) ... On any architecture I know of, ^ and != would be equally efficient here. Alan Stern --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Question on usage of urb-hcpriv field.
On Tue, 11 Oct 2005, Franck wrote: Consider a simple example of reading: spin_lock(urb-lock); if (urb-status == -EINPROGRESS) printk(URB is in progress\n); else printk(URB is not in progress\n); spni_unlock(urb-lock); Now imagine what would happen if the code didn't acquire the lock. The value could be changed by another thread in between the if statement's test and the printk statement. But who cares? The overall effect is exactly the same as if the other thread had changed the value _after_ the printk statement executed. hmm, this example may be correct not because you're _reading_ the value but because printk statement doesn't _use_ urb's data structure. Or because the printk statement doesn't require the URB's internal data not to change. Yes, but reading (or rather, not writing) is also part of it. If you write urb-status without holding urb-lock, you run the risk of the error I described earlier. Remember that the only data protected by urb-lock is urb-status, urb-urb_list, and urb-reject. Your HCD should change nothing but the status. Another point in my hcd is that an urb can already be transfered by hw before hcd-urb_enqueue method is called. Actually as soon as this urb is linked into the corresponding ep's urb list, the hw can send it. Do you think it can be an issue ? Yes. Your code does not own the ep's list, usbcore does. Your HCD should not even be aware of an URB until urb_enqueue is called. You need to maintain your own lists, using the urb-hcpriv private data structure. Well, I have my own lists of active ep (actually it's the same mechanism as sl811-hcd driver by David Brownell). Each active ep have a reference to its associated usbcore ep. It allows to retrieve list of URB for that ep. I suppose that's okay, provided you remember that new entries can be added to the list before your driver has accepted them. What would happen if your urb_enqueue method had to reject the submission because it couldn't allocate memory for the private data structure? The hardware might already be transferring the rejected URB! In that case it can't happen. Allocation happens only when scheduling an ep the first time. At this time this ep in not in my list of active ep so it's not a candidate for transfering URB. So your urb_enqueue method can never fail, except on the first URB for an endpoint? In that case, the cause of your bad kref access must have been something else. If you want to take a look to this hcd, I can send it to you. Your comments are _very_ welcome. While I'd like to help, I'm too busy to read through anything as complex as an HCD. Alan Stern --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [Security] Re: [linux-usb-devel] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, Oct 11, 2005 at 03:13:39PM -0400, Alan Stern wrote: Surely Linux uses entirely original code, with no hangovers from the original ATT Unix... Besides, to the best of my recollection, the two operations are equal in speed on a PDP-11. I've no idea but I don't believe the relative speed of PDP_11 operations is security critical in Linux so can you trim the cc line --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] bug in usb-skeleton.c ?
There appears to be a bug in usb/usb-skeleton.c. At least up
through 2.6.14-rc4. The original code generates a read pipe id for the
write output pipe.
bill rees
--- usb-skeleton.c 2005-09-26 20:09:39.0 -0700
+++ usb-skeleton.mod.c 2005-10-11 14:55:27.815537470 -0700
@@ -272,7 +272,7 @@
}
if (!dev-bulk_out_endpointAddr
- !(endpoint-bEndpointAddress USB_DIR_OUT)
+ !(endpoint-bEndpointAddress USB_DIR_IN)
((endpoint-bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
== USB_ENDPOINT_XFER_BULK)) {
/* we found a bulk out endpoint */
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
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] RE: isp116x suspend/resume problem on Viper board
On Tue, 11 Oct 2005, Ivan Kalatchev wrote: I've tested your new patch. Everything works just fine. Host controller is restarted and alive after board is resumed. The only tricky moment is if user forgot to unmount memory stick before sending board to sleep. Say it was mounted as /dev/sda1 before sleeping. After board resumed, memory stick of course is unaccessable, so I tried to unmount it and mount again as /dev/sda1. But this failes, saying that it's not valid block device. Thing is that I can still mount it fine, but as /dev/sdb1! /dev/sda1 remains bad until I reset board again (resetting USB controller effectively), but this time unmounting memory stick before sleeping. So if anything could be done to have the ability to unmount/mount back device as the same device, when user forget to unmount it before sleeping, that would be great. No, you won't get the same device node back, AFAIK. At least not without reloading the scsi driver(s) if they were built as modules. After reinit of the USB controller holding a mounted storage device, the SCSI layer is convinced that the storage device is dead and won't let you do any operations on it. Take a look at udev. It is meant to solve such a problem. Olav --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] bug in usb-skeleton.c ?
Bill Rees wrote:
There appears to be a bug in usb/usb-skeleton.c. At least up
through 2.6.14-rc4. The original code generates a read pipe id for
the write output pipe.
bill rees
--- usb-skeleton.c 2005-09-26 20:09:39.0 -0700
+++ usb-skeleton.mod.c 2005-10-11 14:55:27.815537470 -0700
@@ -272,7 +272,7 @@
}
if (!dev-bulk_out_endpointAddr
- !(endpoint-bEndpointAddress USB_DIR_OUT)
+ !(endpoint-bEndpointAddress USB_DIR_IN)
((endpoint-bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
== USB_ENDPOINT_XFER_BULK)) {
/* we found a bulk out endpoint */
Nevermind, I patched the wrong kernel.
bill rees
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
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] Re: [vendor-sec] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, Oct 11, 2005 at 11:45:51AM +0200, Harald Welte wrote: 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 ;) Ugh, but it looks like Linus already committed your previous patch, with some changes by him. Care to send a delta from what is currently in his tree (2.6.14-rc4 has it) and this patch? thanks, greg k-h --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ 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] Re: [vendor-sec] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, 11 Oct 2005, Greg KH wrote: Ugh, but it looks like Linus already committed your previous patch, with some changes by him. Care to send a delta from what is currently in his tree (2.6.14-rc4 has it) and this patch? 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.. To some degree it would actually be nice to totally abstract that pid+uid+euid thing out as a structure of its own, and have the signal handling code fill it up (helper inline function in linux/sched.h or something), and have the users just use what to them is a totally opaque signal sender token. That would allow us to improve or change the validation of the thing later. 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) Linus --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
