linux-kernel - Re: [PATCH] Moving spinlock to struct usb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9f29ca150801260736j205b67d2jf9b57d3ac05176a2@mail.gmail.com>
Date:	Sat, 26 Jan 2008 21:06:36 +0530
From:	"Romit Dasgupta" <romlinux@...il.com>
To:	"David Brownell" <david-b@...bell.net>
Cc:	greg@...ah.com, stern@...land.harvard.edu,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Moving spinlock to struct usb_hcd

>
>
> Looking at how this lock is used, contention doesn't look likely
> to be an issue.  It's never held for long ...
yes in the general case but in usb_hcd_flush_endpoint routine it seems
to be held for longer than other routines. I agree that
usb_hcd_flush_endpoint is an infrequently called routine. Normal
systems dont have too many HCs. My computer shows 1 EHCI and 3 OHCIs
so I guess when I connect high speed devices there are less chances of
contention. With more HC this lock might be contended for.
Nevertheless, the right place for the lock seems to be inside usb_hcd.
What do you think?

>
>
> Do you have any proof that contention is an actual problem?
> Because otherwise I see no benefit to such a change.
>
I will try to see what I can find with /proc/lock_stat.

Thanks,
-Romit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/