+++ Prarit Bhargava [28/05/19 10:30 -0400]:
On 5/22/19 1:08 PM, Prarit Bhargava wrote:
On 5/13/19 10:37 AM, Barret Rhoden wrote:
Hi -
Hey Barret, my apologies for not getting back to you earlier. I got caught up
in something that took me away from this issue.
On 5/13/19 7:23 AM, Prari
On 5/22/19 1:08 PM, Prarit Bhargava wrote:
>
>
> On 5/13/19 10:37 AM, Barret Rhoden wrote:
>> Hi -
>>
>
> Hey Barret, my apologies for not getting back to you earlier. I got caught up
> in something that took me away from this issue.
>
>> On 5/13/19 7:23 AM, Prarit Bhargava wrote:
>> [snip]
On 5/13/19 10:37 AM, Barret Rhoden wrote:
> Hi -
>
Hey Barret, my apologies for not getting back to you earlier. I got caught up
in something that took me away from this issue.
> On 5/13/19 7:23 AM, Prarit Bhargava wrote:
> [snip]
>> A module is loaded once for each cpu.
>
> Does one CPU su
Hi -
On 5/13/19 7:23 AM, Prarit Bhargava wrote:
[snip]
A module is loaded once for each cpu.
Does one CPU succeed in loading the module, and the others fail with EEXIST?
My follow-up patch changes from wait_event_interruptible() to
wait_event_interruptible_timeout() so the CPUs are no longer
On 5/10/19 2:42 PM, Barret Rhoden wrote:
> When add_unformed_module() finds an existing module with the same name,
> it waits until the preexisting module finished loading. Prior to commit
> f9a75c1d717f, this meant if the module was either UNFORMED or COMING,
> we'd wait. That commit changed
When add_unformed_module() finds an existing module with the same name,
it waits until the preexisting module finished loading. Prior to commit
f9a75c1d717f, this meant if the module was either UNFORMED or COMING,
we'd wait. That commit changed the check to be !LIVE, so that we'd wait
for UNFORME
6 matches
Mail list logo
