summaryrefslogtreecommitdiffstats
path: root/net/lapb/lapb_iface.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* [NET] LAPB: Fix whitespace errors.YOSHIFUJI Hideaki2007-02-111-3/+3
| | | | | Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [LAPB]: Fix windowsize checkDiego Calleja2006-08-061-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | In bug #6954, Norbert Reinartz reported the following issue: "Function lapb_setparms() in file net/lapb/lapb_iface.c checks if the given parameters are valid. If the given window size is in the range of 8 .. 127, lapb_setparms() fails and returns an error value of LAPB_INVALUE, even if bit LAPB_EXTENDED in parms->mode is set. If bit LAPB_EXTENDED in parms->mode is set and the window size is in the range of 8 .. 127, the first check "(parms->mode & LAPB_EXTENDED)" results true and the second check "(parms->window < 1 || parms->window > 127)" results false. Both checks in conjunction result to false, thus the third check "(parms->window < 1 || parms->window > 7)" is done by fault. This third check results true, so that we leave lapb_setparms() by 'goto out_put'. Seems that this bug doesn't cause any problems, because lapb_setparms() isn't used to change the default values of LAPB. We are using kernel lapb in our software project and also change the default parameters of lapb, so we found this bug" He also pasted a fix, that I've transformated into a patch: Signed-off-by: Diego Calleja <diegocg@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NET]: Conversions from kmalloc+memset to k(z|c)alloc.Panagiotis Issaris2006-07-211-3/+1
| | | | | | Signed-off-by: Panagiotis Issaris <takis@issaris.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+449
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!