于 2014/1/25 1:27, Valdis.Kletnieks@xxxxxx wote: > On Fri, 24 Jan 2014 17:43:35 +0800, parmenides said: > >> CONFIG_BROKEN_ON_SMP: should be set in the kernel configuration, but isn't. > >> I wonder what the meaning of the configuration is. How does it work? Thx! > > Drivers (and all other kernel-mode code, actually) need to do proper locking, > so that if there's a race between code running on 2 different CPUs at the same > time, they don't stomp all over each other (consider the case of one CPU trying > to walk a linked list at the same time that another CPU is deleting an entry > from the list - this can leave the first CPU walking down a now corrupted list > following now-stale pointers). > > There are a lot of old buggy drivers that don't do proper locking. In a > few cases, the drivers are *technically* buggy, but the bugs just happen to > be in code that will manage to work anyhow *if there is only one CPU* (for > instance, wrapped in a IRQ-disabled section). These drivers get BROKEN_ON_SMP > attached, because they can still potentially be useful for people compiling > on architectures that only support 1 processor core, or *need* the driver and > don't care if they only use 1 core of the 4 they have. > > The proper fix is, of course, to put proper locking in the driver - but most > BROKEN_ON_SMP drivers are creeping horrorshows straight out of HP Lovecraft, > and nobody wants to invest the resources needed to fix the abandonware driver. > Does that mean BROKEN_ON_SMP drivers are all tagged, and they are not seen when I 'make menuconfig', if CONFIG_BROKEN_ON_SMP not be set? If so, how these drivers are tagged? _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
