linux-kernel - ARM SMP startup question (regarding gic_secondary

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 31 Mar 2011 13:28:51 -0500
From:	<chris@...ementcode.com>
To:	<linux-kernel@...r.kernel.org>
Subject: ARM SMP startup question (regarding gic_secondary_init)

 I was looking at a some of the SMP code in the arm mach types. Inside 
 the platform_secondary_init function they all seem to follow the same 
 basic procedure:

   //secondary core code//
   gic_secondary_init(0);
   spin_lock(&boot_lock);
   spin_unlock(&boot_lock);

 I'm porting to a board myself, so I copied that structure to get 
 started. While the secondary processor is in the first bit of code, the 
 boot processor is here:

   //boot core code//
   spin_lock(&boot_lock);
   while (time_before(jiffies, timeout));
   /*
    * now the secondary core is starting up let it run its
    * calibrations, then wait for it to finish
    */
   spin_unlock(&boot_lock);

 which causes a deadlock because jiffies isn't being incremented, and 
 the boot cpu has a lock on boot_lock that the secondary processor needs 
 to sync with. Upon closer inspection gic_secondary_init uses the 
 following lines of code:

   /*
    * Deal with the banked PPI and SGI interrupts - disable all
    * PPI interrupts, ensure all SGI interrupts are enabled.
    */
   writel(0xffff0000, dist_base + GIC_DIST_ENABLE_CLEAR);
   writel(0x0000ffff, dist_base + GIC_DIST_ENABLE_SET);

 The timer for the scheduler seems to be attached via the GIC PPI 
 interrupts. I guess it makes sense that we don't need a scheduler while 
 a CPU is booting. The problem is that even ignoring platform (or should 
 I say mach?) specific code that uses jiffies as timer and timeout code, 
 core ARM files rely on it. For example, after disabling timer interrupts 
 the secondary core gets to the calibrate_delay function, which also has 
 the jiffy loops that never end. If I replace
   writel(0x0000ffff, dist_base + GIC_DIST_ENABLE_SET);
 with
   writel(0xffffffff, dist_base + GIC_DIST_ENABLE_SET);
 to avoid disabling the timer interrupts the system boots without any 
 problems, and both cpus work happily together.

 I should note that I am NOT yet using local timers.

 This is actually by first post to the LKML, I hope that I've asked the 
 right questions and made my points efficiently enough.

 I've read a few ARM related posts here, and I'm still not clear on what 
 is meant by "pointless churn". I understand that it means code is 
 constantly being changed with little to no effect on the kernel, but 
 what code are people refering to?

 Thanks,
 -Chris

--
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/