From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=3.0 tests=DATE_IN_PAST_03_06, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 542FFC4360F for ; Wed, 3 Apr 2019 13:31:55 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 00A252075E for ; Wed, 3 Apr 2019 13:31:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kroah.com header.i=@kroah.com header.b="DX0hT77X"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="cB4eNCgT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 00A252075E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kroah.com Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.91) (envelope-from ) id 1hBfzK-0006zs-CW; Wed, 03 Apr 2019 09:31:34 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hBfzI-0006zl-2q for kernelnewbies@kernelnewbies.org; Wed, 03 Apr 2019 09:31:32 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3D9BF62CD; Wed, 3 Apr 2019 09:31:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 03 Apr 2019 09:31:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=gZIgs4Ou7SwY5NayxP1bq18ZjbQ CMDORtJGHmTEHOXI=; b=DX0hT77X6sQALZLZsWWObSq+WtaHQudBwNIbxSavNqk VjF8xR0jBxiTIe8fjjGKvEhJNsRC4Xd9OMgxZQAYGhJIvuqBVPtDfU1jDUvxE54F JBCOX4dsCp0YKZWjC0RbekwL4jQrkaVUZihQwSLqcpeusjN7eD5EwM+7teP9t9d6 jMAedp75WOaLxMAzeejl/7oG9Lazmvv+H2uNwS4OEsmpyR4+aPCb6gMlKNHM41pr vGieFFXE2CLGT/dCswrw/D7rdIAnBfwwFZx4ZCcQc1T+vkA8TrQRSq/dm+qHCLfS VeSWRd+9x2hMWoTJ7xaPyS1oXtb9bIbiF08zzzkT1Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gZIgs4 Ou7SwY5NayxP1bq18ZjbQCMDORtJGHmTEHOXI=; b=cB4eNCgTzOptAClbrSs7hr JaAl2bnSzgiPQTr1pHhiQ7mKq/irzqypBlC4cMqUxGToZSgiAciQEDG99JEaTnVa AVX4uKc7RV0i1vbLYTLTWoDft7Ix3wQ3aBdbVJSzo/jxKrnbkKjMQDNUT6/GDpKt L9pgaI86LrtfEpSUlm19rYB3wo6fDPK6MGnemfWF17N38Wing9dFNvj5xkUp1jLa 8VsoBSjLt1QxdRW52Y5ryFsdj3EwbweLEV7Vs+SG8Ed8Va9QhjQwmGVEyil4yPKZ Rc0Ye9+5aSODI9C8Efd5yW550L9LHu/qwFOvIJZ17A5eRi17fQkSL1cqQlBScaqg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdefgdefleculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredv necuhfhrohhmpefirhgvghcumffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucfkph epvddujedruddtuddrudektddrudefieenucfrrghrrghmpehmrghilhhfrhhomhepghhr vghgsehkrhhorghhrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (217-101-180-136.cable.dynamic.v4.ziggo.nl [217.101.180.136]) by mail.messagingengine.com (Postfix) with ESMTPA id DC249E4910; Wed, 3 Apr 2019 09:31:28 -0400 (EDT) Date: Wed, 3 Apr 2019 11:48:08 +0200 From: Greg KH To: Martin Christian Subject: Re: Unexpected scheduling with mutexes Message-ID: <20190403094808.GA11892@kroah.com> References: <20190329200158.GF12004@kroah.com> <8f951fe5-f3bd-367b-e6ac-0ac48c43ec78@secunet.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8f951fe5-f3bd-367b-e6ac-0ac48c43ec78@secunet.com> User-Agent: Mutt/1.11.4 (2019-03-13) Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Wed, Apr 03, 2019 at 11:33:56AM +0200, Martin Christian wrote: > >> For certain values of `X` there is a significant difference in size > >> between the two files, which I don't expect. > >> > >> A read call to the driver does the following: > >> 1. `mutex_lock_interruptible(iolock)` > >> 2. `usb_bulk_msg(dev, pipe, buf, X, timeout)` > >> 3. `mutex_unlock(iolock)` > >> 4. `copy_to_user(buf)` > > > > What are these values of X that cause differences here? > > Starting around 1k character device A gets more data until it turns over > at around 4K. Request size from 10K yield the expected data rates. Those are huge USB data stream sizes, what is the size of your USB endpoints? By doing large transfers like this, you are causing the USB core to do all the work (which is fine), but while that happens, lots of other things happen at the same time, making trying to measure things much more difficult. > Character device A is a "real" random source and returns data much > slower than device B, which is a pseudo random source. So those map to different USB device endpoints? > > But if you are trying to somehow create a real api that you have to > > enforce the passing off of writing data from two different character > > devices in an interleaved format, you are doing this totally wrong, as > > this is not going to work with a simple mutex, as you have found out. > > As mentioned above, the USB device provides two different streams of > random. But the device can process only one request at a time. Also I > didn't want to have too much dynamic memory allocation, because I would > need to allocate up to 64KB kernel memory on each open. So your USB device can not handle data from different endpoints at the same time? Or is it multiplexing it on the same endpoint? You need to provide a bit more information about your device for us to be able to help you out better. > That's because the USB device is designed to provide up to 64K of random > in a single "request". A request has a header and footer "protecting" > the request as a whole from data confusion. Who are you protecting the request from being confused from? The kernel? Userspace? Something else? Why not just tie your device into the kernel's random number system like other USB devices do that provide good entropy to the system? That way you don't have to do crazy things with character streams and blocking requests :) > To make things simpler I decided to just allow one user space process at > a time for each source - which is enough for our application. But yes, > that could probably also got to user space. Again, why not just use the random services provided by the kernel, and have your device feed that? That way everyone benefits and you don't have to do odd things and create a custom user api that no one else can use. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies