* [PATCH 0/10] use safer test on the result of find_first_zero_bit @ 2014-06-04 9:07 Julia Lawall 2014-06-04 9:07 ` [PATCH 3/10] video: " Julia Lawall 2014-06-04 9:35 ` [PATCH 0/10] " Geert Uytterhoeven 0 siblings, 2 replies; 14+ messages in thread From: Julia Lawall @ 2014-06-04 9:07 UTC (permalink / raw) To: linux-rdma Cc: devel, linux-s390, linux-fbdev, linux-scsi, iss_storagedev, linux-sh, kernel-janitors, linux-wireless, linux-kernel, ath10k, adi-buildroot-devel, netdev Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may return a larger number than the maximum position argument if that position is not a multiple of BITS_PER_LONG. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 3/10] video: use safer test on the result of find_first_zero_bit 2014-06-04 9:07 [PATCH 0/10] use safer test on the result of find_first_zero_bit Julia Lawall @ 2014-06-04 9:07 ` Julia Lawall 2014-06-23 11:50 ` Tomi Valkeinen 2014-06-04 9:35 ` [PATCH 0/10] " Geert Uytterhoeven 1 sibling, 1 reply; 14+ messages in thread From: Julia Lawall @ 2014-06-04 9:07 UTC (permalink / raw) To: Jean-Christophe Plagniol-Villard Cc: kernel-janitors, Tomi Valkeinen, linux-fbdev, linux-kernel From: Julia Lawall <Julia.Lawall@lip6.fr> Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may return a larger number than the maximum position argument if that position is not a multiple of BITS_PER_LONG. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e1,e2,e3; statement S1,S2; @@ e1 = find_first_zero_bit(e2,e3) ... if (e1 - = + > e3) S1 else S2 // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> --- drivers/video/fbdev/sh_mobile_meram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -u -p a/drivers/video/fbdev/sh_mobile_meram.c b/drivers/video/fbdev/sh_mobile_meram.c --- a/drivers/video/fbdev/sh_mobile_meram.c +++ b/drivers/video/fbdev/sh_mobile_meram.c @@ -222,7 +222,7 @@ static int meram_plane_alloc(struct sh_m unsigned long idx; idx = find_first_zero_bit(&priv->used_icb, 28); - if (idx = 28) + if (idx >= 28) return -ENOMEM; plane->cache = &priv->icbs[idx]; ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/10] video: use safer test on the result of find_first_zero_bit 2014-06-04 9:07 ` [PATCH 3/10] video: " Julia Lawall @ 2014-06-23 11:50 ` Tomi Valkeinen 2014-06-23 14:12 ` Julia Lawall 0 siblings, 1 reply; 14+ messages in thread From: Tomi Valkeinen @ 2014-06-23 11:50 UTC (permalink / raw) To: Julia Lawall, Jean-Christophe Plagniol-Villard Cc: kernel-janitors, linux-fbdev, linux-kernel [-- Attachment #1: Type: text/plain, Size: 323 bytes --] On 04/06/14 12:07, Julia Lawall wrote: > From: Julia Lawall <Julia.Lawall@lip6.fr> > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may > return a larger number than the maximum position argument if that position > is not a multiple of BITS_PER_LONG. Thanks, queued for 3.17. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/10] video: use safer test on the result of find_first_zero_bit 2014-06-23 11:50 ` Tomi Valkeinen @ 2014-06-23 14:12 ` Julia Lawall 2014-06-24 7:56 ` Tomi Valkeinen 0 siblings, 1 reply; 14+ messages in thread From: Julia Lawall @ 2014-06-23 14:12 UTC (permalink / raw) To: Tomi Valkeinen Cc: Julia Lawall, Jean-Christophe Plagniol-Villard, kernel-janitors, linux-fbdev, linux-kernel On Mon, 23 Jun 2014, Tomi Valkeinen wrote: > On 04/06/14 12:07, Julia Lawall wrote: > > From: Julia Lawall <Julia.Lawall@lip6.fr> > > > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may > > return a larger number than the maximum position argument if that position > > is not a multiple of BITS_PER_LONG. > > Thanks, queued for 3.17. No, sorry you can drop it. It doesn't hurt anything, but it is not necessary either. Returning a larger number is actually not possible. julia ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/10] video: use safer test on the result of find_first_zero_bit 2014-06-23 14:12 ` Julia Lawall @ 2014-06-24 7:56 ` Tomi Valkeinen 0 siblings, 0 replies; 14+ messages in thread From: Tomi Valkeinen @ 2014-06-24 7:56 UTC (permalink / raw) To: Julia Lawall Cc: Jean-Christophe Plagniol-Villard, kernel-janitors, linux-fbdev, linux-kernel [-- Attachment #1: Type: text/plain, Size: 595 bytes --] On 23/06/14 17:12, Julia Lawall wrote: > On Mon, 23 Jun 2014, Tomi Valkeinen wrote: > >> On 04/06/14 12:07, Julia Lawall wrote: >>> From: Julia Lawall <Julia.Lawall@lip6.fr> >>> >>> Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may >>> return a larger number than the maximum position argument if that position >>> is not a multiple of BITS_PER_LONG. >> >> Thanks, queued for 3.17. > > No, sorry you can drop it. It doesn't hurt anything, but it is not > necessary either. Returning a larger number is actually not possible. Ok, dropped. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 9:07 [PATCH 0/10] use safer test on the result of find_first_zero_bit Julia Lawall 2014-06-04 9:07 ` [PATCH 3/10] video: " Julia Lawall @ 2014-06-04 9:35 ` Geert Uytterhoeven [not found] ` <CAMuHMdXsoFUXj4jLMWN6NY7Um19KwWO9Rhx=9=gqWu_K5Ev2kQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 1 reply; 14+ messages in thread From: Geert Uytterhoeven @ 2014-06-04 9:35 UTC (permalink / raw) To: Julia Lawall Cc: driverdevel, linux-s390, Linux Fbdev development list, scsi, iss_storagedev, Linux-sh list, linux-rdma, linux-wireless, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, ath10k, adi-buildroot-devel, netdev@vger.kernel.org Hi Julia, On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall <Julia.Lawall@lip6.fr> wrote: > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may > return a larger number than the maximum position argument if that position > is not a multiple of BITS_PER_LONG. Shouldn't this be fixed in find_first_zero_bit() instead? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAMuHMdXsoFUXj4jLMWN6NY7Um19KwWO9Rhx=9=gqWu_K5Ev2kQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH 0/10] use safer test on the result of find_first_zero_bit [not found] ` <CAMuHMdXsoFUXj4jLMWN6NY7Um19KwWO9Rhx=9=gqWu_K5Ev2kQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2014-06-04 9:38 ` Julia Lawall 2014-06-04 9:46 ` David Laight 0 siblings, 1 reply; 14+ messages in thread From: Julia Lawall @ 2014-06-04 9:38 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Julia Lawall, linux-rdma, kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Fbdev development list, Linux-sh list, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, driverdevel, iss_storagedev-VXdhtT5mjnY, scsi, linux-s390, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: > Hi Julia, > > On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall <Julia.Lawall@lip6.fr> wrote: > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may > > return a larger number than the maximum position argument if that position > > is not a multiple of BITS_PER_LONG. > > Shouldn't this be fixed in find_first_zero_bit() instead? OK, I could do that as well. Most of the callers currently test with >=. Should they be left as is, or changed to use =? julia ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 9:38 ` Julia Lawall @ 2014-06-04 9:46 ` David Laight 2014-06-04 9:52 ` Julia Lawall 0 siblings, 1 reply; 14+ messages in thread From: David Laight @ 2014-06-04 9:46 UTC (permalink / raw) To: 'Julia Lawall', Geert Uytterhoeven Cc: linux-rdma, kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Fbdev development list, Linux-sh list, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, driverdevel, iss_storagedev-VXdhtT5mjnY@public.gmane.org, scsi, linux-s390, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org From: Julia Lawall > On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: > > > Hi Julia, > > > > On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall <Julia.Lawall@lip6.fr> wrote: > > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may > > > return a larger number than the maximum position argument if that position > > > is not a multiple of BITS_PER_LONG. > > > > Shouldn't this be fixed in find_first_zero_bit() instead? > > OK, I could do that as well. Most of the callers currently test with >=. > Should they be left as is, or changed to use =? Do we want to add an extra test to find_first_zero_bit() and effectively slow down all the calls - especially those where the length is a multiple of 8 (probably the most common). Maybe the documented return code should be changed to allow for the existing behaviour. David ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 9:46 ` David Laight @ 2014-06-04 9:52 ` Julia Lawall 2014-06-04 10:55 ` Geert Uytterhoeven 0 siblings, 1 reply; 14+ messages in thread From: Julia Lawall @ 2014-06-04 9:52 UTC (permalink / raw) To: David Laight Cc: 'Julia Lawall', Geert Uytterhoeven, linux-rdma, kernel-janitors@vger.kernel.org, Linux Fbdev development list, Linux-sh list, linux-kernel@vger.kernel.org, ath10k@lists.infradead.org, linux-wireless, netdev@vger.kernel.org, driverdevel, iss_storagedev@hp.com, scsi, linux-s390, adi-buildroot-devel@lists.sourceforge.net On Wed, 4 Jun 2014, David Laight wrote: > From: Julia Lawall > > On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: > > > > > Hi Julia, > > > > > > On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall <Julia.Lawall@lip6.fr> wrote: > > > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may > > > > return a larger number than the maximum position argument if that position > > > > is not a multiple of BITS_PER_LONG. > > > > > > Shouldn't this be fixed in find_first_zero_bit() instead? > > > > OK, I could do that as well. Most of the callers currently test with >=. > > Should they be left as is, or changed to use =? > > Do we want to add an extra test to find_first_zero_bit() and effectively > slow down all the calls - especially those where the length is a > multiple of 8 (probably the most common). Currently, most of the calls test with >=, and most of the others seem to need to (either the size value did not look like a multiple of anything in particular, or it was eg read from a device). Note that it is BITS_PER_LONG, so it seems like it is typically 32 or 64, not 8. > Maybe the documented return code should be changed to allow for the > existing behaviour. Sorry, I'm not sure to understand what you suggest here. thanks, julia ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 9:52 ` Julia Lawall @ 2014-06-04 10:55 ` Geert Uytterhoeven 2014-06-04 11:00 ` Julia Lawall 0 siblings, 1 reply; 14+ messages in thread From: Geert Uytterhoeven @ 2014-06-04 10:55 UTC (permalink / raw) To: Julia Lawall Cc: driverdevel, linux-s390, Linux Fbdev development list, scsi, iss_storagedev@hp.com, Linux-sh list, linux-rdma, linux-wireless, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, ath10k@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, David Laight, Arnd Bergmann, netdev@vger.kernel.org Hi Julia, On Wed, Jun 4, 2014 at 11:52 AM, Julia Lawall <julia.lawall@lip6.fr> wrote: >> Maybe the documented return code should be changed to allow for the >> existing behaviour. > > Sorry, I'm not sure to understand what you suggest here. include/asm-generic/bitops/find.h: | /** | * find_first_zero_bit - find the first cleared bit in a memory region | * @addr: The address to start the search at | * @size: The maximum number of bits to search | * | * Returns the bit number of the first cleared bit. | * If no bits are zero, returns @size. "If no bits are zero, returns @size or a number larger than @size." | */ | extern unsigned long find_first_zero_bit(const unsigned long *addr, | unsigned long size); Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 10:55 ` Geert Uytterhoeven @ 2014-06-04 11:00 ` Julia Lawall 2014-06-04 11:07 ` Geert Uytterhoeven 0 siblings, 1 reply; 14+ messages in thread From: Julia Lawall @ 2014-06-04 11:00 UTC (permalink / raw) To: Geert Uytterhoeven Cc: driverdevel, linux-s390, Linux Fbdev development list, scsi, iss_storagedev@hp.com, Linux-sh list, linux-rdma, linux-wireless, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, ath10k@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, Julia Lawall, David Laight, Arnd Bergmann, netdev@vger.kernel.org On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: > Hi Julia, > > On Wed, Jun 4, 2014 at 11:52 AM, Julia Lawall <julia.lawall@lip6.fr> wrote: > >> Maybe the documented return code should be changed to allow for the > >> existing behaviour. > > > > Sorry, I'm not sure to understand what you suggest here. > > include/asm-generic/bitops/find.h: > > | /** > | * find_first_zero_bit - find the first cleared bit in a memory region > | * @addr: The address to start the search at > | * @size: The maximum number of bits to search > | * > | * Returns the bit number of the first cleared bit. > | * If no bits are zero, returns @size. > > "If no bits are zero, returns @size or a number larger than @size." OK, thanks. I was only looking at the C code. But the C code contains a loop that is followed by: if (!size) return result; tmp = *p; found_first: tmp |= ~0UL << size; if (tmp = ~0UL) /* Are any bits zero? */ return result + size; /* Nope. */ In the first return, it would seem that result = size. Could the second one be changed to just return size? It should not hurt performance. julia > > | */ > | extern unsigned long find_first_zero_bit(const unsigned long *addr, > | unsigned long size); > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 11:00 ` Julia Lawall @ 2014-06-04 11:07 ` Geert Uytterhoeven 2014-06-04 13:12 ` Julia Lawall 0 siblings, 1 reply; 14+ messages in thread From: Geert Uytterhoeven @ 2014-06-04 11:07 UTC (permalink / raw) To: Julia Lawall Cc: David Laight, linux-rdma, kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Fbdev development list, Linux-sh list, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, driverdevel, iss_storagedev-VXdhtT5mjnY@public.gmane.org, scsi, linux-s390, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Arnd Bergmann Hi Julia, On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall <julia.lawall@lip6.fr> wrote: > OK, thanks. I was only looking at the C code. > > But the C code contains a loop that is followed by: > > if (!size) > return result; > tmp = *p; > > found_first: > tmp |= ~0UL << size; > if (tmp = ~0UL) /* Are any bits zero? */ > return result + size; /* Nope. */ > > In the first return, it would seem that result = size. Could the second > one be changed to just return size? It should not hurt performance. "size" may have been changed between function entry and this line. So you have to store it in a temporary. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 11:07 ` Geert Uytterhoeven @ 2014-06-04 13:12 ` Julia Lawall 2014-06-04 13:34 ` David Laight 0 siblings, 1 reply; 14+ messages in thread From: Julia Lawall @ 2014-06-04 13:12 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Julia Lawall, David Laight, linux-rdma, kernel-janitors@vger.kernel.org, Linux Fbdev development list, Linux-sh list, linux-kernel@vger.kernel.org, ath10k@lists.infradead.org, linux-wireless, netdev@vger.kernel.org, driverdevel, iss_storagedev@hp.com, scsi, linux-s390, adi-buildroot-devel@lists.sourceforge.net, Arnd Bergmann, sebott On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: > Hi Julia, > > On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall <julia.lawall@lip6.fr> wrote: > > OK, thanks. I was only looking at the C code. > > > > But the C code contains a loop that is followed by: > > > > if (!size) > > return result; > > tmp = *p; > > > > found_first: > > tmp |= ~0UL << size; > > if (tmp = ~0UL) /* Are any bits zero? */ > > return result + size; /* Nope. */ > > > > In the first return, it would seem that result = size. Could the second > > one be changed to just return size? It should not hurt performance. > > "size" may have been changed between function entry and this line. > So you have to store it in a temporary. Sorry, after reflection it seems that indeed size + result is always the original size, so it is actually all of the code that uses >= that is doing something unnecessary. = for the failure test is fine. julia ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH 0/10] use safer test on the result of find_first_zero_bit 2014-06-04 13:12 ` Julia Lawall @ 2014-06-04 13:34 ` David Laight 0 siblings, 0 replies; 14+ messages in thread From: David Laight @ 2014-06-04 13:34 UTC (permalink / raw) To: 'Julia Lawall', Geert Uytterhoeven Cc: linux-rdma, kernel-janitors@vger.kernel.org, Linux Fbdev development list, Linux-sh list, linux-kernel@vger.kernel.org, ath10k@lists.infradead.org, linux-wireless, netdev@vger.kernel.org, driverdevel, iss_storagedev@hp.com, scsi, linux-s390, adi-buildroot-devel@lists.sourceforge.net, Arnd Bergmann, sebott@linux.vnet.ibm.com From: Julia Lawall > On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: > > > Hi Julia, > > > > On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall <julia.lawall@lip6.fr> wrote: > > > OK, thanks. I was only looking at the C code. > > > > > > But the C code contains a loop that is followed by: > > > > > > if (!size) > > > return result; > > > tmp = *p; > > > > > > found_first: > > > tmp |= ~0UL << size; > > > if (tmp = ~0UL) /* Are any bits zero? */ > > > return result + size; /* Nope. */ > > > > > > In the first return, it would seem that result = size. Could the second > > > one be changed to just return size? It should not hurt performance. > > > > "size" may have been changed between function entry and this line. > > So you have to store it in a temporary. > > Sorry, after reflection it seems that indeed size + result is always the > original size, so it is actually all of the code that uses >= that is > doing something unnecessary. = for the failure test is fine. There is nothing wrong with defensive coding. The 'tmp |= ~0UL << size' ensures that the return value is 'correct' when there are no bits set. The function could have been defined so that this wasn't needed. If you assume that the 'no zero bits' is unlikely, then checking the return value from ffz() could well be slightly faster. Not that anything is likely to notice. David ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-06-24 7:56 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-04 9:07 [PATCH 0/10] use safer test on the result of find_first_zero_bit Julia Lawall 2014-06-04 9:07 ` [PATCH 3/10] video: " Julia Lawall 2014-06-23 11:50 ` Tomi Valkeinen 2014-06-23 14:12 ` Julia Lawall 2014-06-24 7:56 ` Tomi Valkeinen 2014-06-04 9:35 ` [PATCH 0/10] " Geert Uytterhoeven [not found] ` <CAMuHMdXsoFUXj4jLMWN6NY7Um19KwWO9Rhx=9=gqWu_K5Ev2kQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-06-04 9:38 ` Julia Lawall 2014-06-04 9:46 ` David Laight 2014-06-04 9:52 ` Julia Lawall 2014-06-04 10:55 ` Geert Uytterhoeven 2014-06-04 11:00 ` Julia Lawall 2014-06-04 11:07 ` Geert Uytterhoeven 2014-06-04 13:12 ` Julia Lawall 2014-06-04 13:34 ` David Laight
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).