Although in general binary searching allows one to find patches that introduce reproducible bugs relatively quickly, you should be aware that it may fail, as well as any other debugging technique.
First of all, it tends to single out patches that expose problems, but they need not be the same as the patches that actually introduce them. Usually, the patch that introduces bugs breaks the kernel, but sometimes the breakage results from some other changes that would work just fine if the bugs were not present. You should always remember about it, especially when you report the problem to the kernel developers (ie. never assume blindly that the patch identified as ''bad'' by a bisection must be buggy).
Second, in some quite rare situations, the patch that introduces the problem observed by you simply cannot be identified. For example, there may be two or more patches that introduce problems with similar symptoms and in that case it is difficult to say what you are really observing. Apart from this, the buggy patch may belong to a series of several patches depending on each other and you can only compile the kernel with either all of them, or none of them applied. Moreover, two or more such series of patches may be mixed within the tree in a fashion that makes them impossible to untangle. If that happens, you will only be able to identify a range of commits including the buggy patch and that need not be very useful.
It is also possible to make a mistake in binary searching, even if you are
using git-bisect. Yes, it is. For instance, if you run
'git-bisect good' instead of 'git-bisect bad', or vice versa, by
mistake at one point, the entire procedure will lead to nowhere. Another common
mistake is to run 'make oldconfig' (see Section 1.6) in
every step of bisection in such a way that the kernel configuration is slightly
different each time. This may cause the options that actually trigger the bug
to be turned on and off in the process, in which case the binary search will not
lead to any consistent result. To avoid this, it is recommended to preserve the
kernel configuration file known to trigger the bug and copy it to the build
directory (usually it is the same as the kernel source directory - see
Section 1.6 for details) before each compilation of the kernel
(you may be asked to set or unset some options anyway and in that case you will
need to remember the appropriate settings and apply them every time in the same
way).
Finally, if you know something about the series of patches containing the buggy one, you can make the binary search for it end (or converge, as it is usually said) faster. Namely, knowing what changes are made by different patches in the series, you can manually skip the patches that are surely not related to the observed problem. For example, if you have found a bug related to a file system, you should be able to omit the patches that are only related to networking, since most likely they have nothing to do with the bug. This way you can save several kernel compilations, which may be equivalent to a fair amount of time.