* Re: [PATCH] fix memory leak in mm/slab.c::alloc_kmemlist() (try #2)
From: Pekka Enberg @ 2006-03-19 18:40 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel, Andrew Morton, Christoph Lameter
In-Reply-To: <200603182137.08521.jesper.juhl@gmail.com>
On 3/18/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> Currently the only caller of alloc_kmemlist() will BUG() if alloc_kmemlist()
> fails, but that doesn't mean we shouldn't clean up properly IMHO. Also, the
> caller (do_tune_cpucache()) could maybe be changed in the future to do
> something more clever than just BUG() and in that case we really shouldn't
> be leaking memory when we return -ENOMEM.
Yeah, and BUG() can be no-op for embedded.
On 3/18/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> The patch has been compile and boot tested on x86, but since I'm not very
> intimate with the slab code I'd appreciate it if someone would take a close
> look on the changes before merging them.
You probably didn't hit the error path on your x86 box. The patch
looks good to me for -mm although there's few comments below.
> +/*
> + If one or more allocations fail we need to undo all allocations done up to
> + this point.
> + Unfortunately this means yet another loop, but since this only happens on
> + failure and frees up memory in a memory-tight situation, it's not too bad.
> + */
The formatting of this comment looks strange.
> + for_each_online_node(node) {
> + if (count <= 0)
> + break;
> + if (cachep->nodelists[node]) {
Would probably make sense to extract the above expression into local
variable to reduce kernel text size.
> + kfree(cachep->nodelists[node]->shared);
> + free_alien_cache(cachep->nodelists[node]->alien);
> + kfree(cachep->nodelists[node]);
> + cachep->nodelists[node] = NULL;
> + }
> + count--;
> + }
> + return -ENOMEM;
^ permalink raw reply
* Re: + stack-corruption-detector.patch added to -mm tree
From: Matt Mackall @ 2006-03-19 18:26 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-kernel, mingo, Andrew Morton
In-Reply-To: <Pine.LNX.4.63.0603082215330.4484@cuia.boston.redhat.com>
On Wed, Mar 08, 2006 at 10:16:50PM -0500, Rik van Riel wrote:
> On Wed, 8 Mar 2006, akpm@osdl.org wrote:
>
> > - memset(ret, 0, THREAD_SIZE); \
> > + memset(ret, 0x55, THREAD_SIZE); \
>
> Xen uses 0x55 as a poison pattern too. I wonder if we should
> change this one (this one's newer ;)) to something else.
I think we should have a central poison.h file.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH 001/001] PCI: PCI quirk for Asus A8V and A8V Deluxe motherboards
From: Måns Rullgård @ 2006-03-19 18:36 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <dvk79k$hf4$1@sea.gmane.org>
Andras Mantia <amantia@kde.org> writes:
>>> Anyway, my suggestion remains, that the
>>> + if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
>>> + return;
>>> + if (dev->device != PCI_DEVICE_ID_VIA_8237)
>>> + return;
>>>
>>> might be not needed at all as it is not ASUS specific.
>>
>> Doesn't it depend on the BIOS? My BIOS lets me choose between
>> "automatic" and "disabled" for the onboard sound.
>
> I don't see how that setting could change the device ID or the vendor ID. As
> I understood the above code will simply not try to enable the sound device
> if:
> a) the vendor is not ASUSTEK
> b) the device is not ID is not PCI_DEVICE_ID_VIA_8237
>
> For a) it means that an MSI/Epox/whatever board with the same VIA chipset
> and the same problem will not be handled. For b) see my previous comment
It is the BIOS that disables the onboard sound if it detects a PCI
sound card. Chances are other vendors use different BIOS
configurations that do not automatically disable things. I don't know
if messing with those bits might do something bad on another board.
--
Måns Rullgård
mru@inprovide.com
^ permalink raw reply
* Re: [PATCH] -mm: Small CFQ I/O sched optimization
From: Andreas Mohr @ 2006-03-19 18:29 UTC (permalink / raw)
To: Jens Axboe; +Cc: akpm, linux-kernel
In-Reply-To: <20060315185240.GV3595@suse.de>
Hi,
[new patch below]
On Wed, Mar 15, 2006 at 07:52:40PM +0100, Jens Axboe wrote:
> On Wed, Mar 15 2006, Andreas Mohr wrote:
> > During some heavy testing on a single-HDD UP P3/700 my instrumentation showed
> > that case 0 was the *only* thing occurring, no request wrapping ever inside
> > this function.
> > Is that expected behaviour??
>
> Hmm that does sound a little strange - care to do the same
> instrumentation for 'as' to see if this is just a 'cfq' anomaly?
Indeed, this is CFQ-only, AS gets much less uniform data passed in.
> > +#define CFQ_RQ1_WRAP 0x01 /* request 1 wraps */
> > +#define CFQ_RQ2_WRAP 0x02 /* request 2 wraps */
>
> Please put these near where they are used, it's a little confusing to
> have to go look for them. They only make sense in cfq_choose_req().
Done.
> > * Lifted from AS - choose which of crq1 and crq2 that is best served now.
> > - * We choose the request that is closest to the head right now. Distance
> > + * We choose the request that is closest to the head right now. Distances
> > * behind the head are penalized and only allowed to a certain extent.
>
> I sort-of prefer 'distance' here, you may want to change that to an 'is'
> though :-)
Right, that's better.
> > + /* by doing switch() on the bit mask "wrap" we avoid having to
> > + * check two variables for all permutations: --> faster! */
> Multiple line comments have /* and */ on a separate line.
Oh, indeed, fixed.
> Andrew will ask you to move that 'case' to be lined up with the
> 'switch'.
Done.
Created new CFQ patch plus equivalent patch to AS (which additionally
resolves the "shut up, gcc" part in a more elegant way as used in CFQ).
Also now added a comment about the "both crqs wrapped" case.
Thanks,
Signed-off-by: Andreas Mohr <andi@lisas.de>
--- linux-2.6.16-rc6-mm2/block/cfq-iosched.c.orig 2006-03-20 03:14:26.000000000 +0100
+++ linux-2.6.16-rc6-mm2/block/cfq-iosched.c 2006-03-20 00:00:24.000000000 +0100
@@ -362,14 +362,16 @@
/*
* Lifted from AS - choose which of crq1 and crq2 that is best served now.
* We choose the request that is closest to the head right now. Distance
- * behind the head are penalized and only allowed to a certain extent.
+ * behind the head is penalized and only allowed to a certain extent.
*/
static struct cfq_rq *
cfq_choose_req(struct cfq_data *cfqd, struct cfq_rq *crq1, struct cfq_rq *crq2)
{
sector_t last, s1, s2, d1 = 0, d2 = 0;
- int r1_wrap = 0, r2_wrap = 0; /* requests are behind the disk head */
unsigned long back_max;
+#define CFQ_RQ1_WRAP 0x01 /* request 1 wraps */
+#define CFQ_RQ2_WRAP 0x02 /* request 2 wraps */
+ unsigned wrap = 0; /* bit mask: requests behind the disk head? */
if (crq1 == NULL || crq1 == crq2)
return crq2;
@@ -401,35 +403,47 @@
else if (s1 + back_max >= last)
d1 = (last - s1) * cfqd->cfq_back_penalty;
else
- r1_wrap = 1;
+ wrap |= CFQ_RQ1_WRAP;
if (s2 >= last)
d2 = s2 - last;
else if (s2 + back_max >= last)
d2 = (last - s2) * cfqd->cfq_back_penalty;
else
- r2_wrap = 1;
+ wrap |= CFQ_RQ2_WRAP;
/* Found required data */
- if (!r1_wrap && r2_wrap)
- return crq1;
- else if (!r2_wrap && r1_wrap)
- return crq2;
- else if (r1_wrap && r2_wrap) {
- /* both behind the head */
- if (s1 <= s2)
+
+ /*
+ * By doing switch() on the bit mask "wrap" we avoid having to
+ * check two variables for all permutations: --> faster!
+ */
+ switch (wrap) {
+ case 0: /* common case for CFQ: crq1 and crq2 not wrapped */
+ if (d1 < d2)
return crq1;
- else
+ else if (d2 < d1)
return crq2;
- }
+ else {
+ if (s1 >= s2)
+ return crq1;
+ else
+ return crq2;
+ }
- /* Both requests in front of the head */
- if (d1 < d2)
+ case CFQ_RQ2_WRAP:
return crq1;
- else if (d2 < d1)
+ case CFQ_RQ1_WRAP:
return crq2;
- else {
- if (s1 >= s2)
+ case (CFQ_RQ1_WRAP|CFQ_RQ2_WRAP): /* both crqs wrapped */
+ default:
+ /*
+ * Since both rqs are wrapped,
+ * start with the one that's further behind head
+ * (--> only *one* back seek required),
+ * since back seek takes more time than forward.
+ */
+ if (s1 <= s2)
return crq1;
else
return crq2;
--- linux-2.6.16-rc6-mm2/block/as-iosched.c.orig 2006-03-20 03:14:21.000000000 +0100
+++ linux-2.6.16-rc6-mm2/block/as-iosched.c 2006-03-19 21:31:28.000000000 +0100
@@ -460,8 +460,11 @@
as_choose_req(struct as_data *ad, struct as_rq *arq1, struct as_rq *arq2)
{
int data_dir;
- sector_t last, s1, s2, d1, d2;
- int r1_wrap=0, r2_wrap=0; /* requests are behind the disk head */
+ sector_t last, s1, s2, d1 = 0, d2 = 0;
+#define AS_RQ1_WRAP 0x01 /* request 1 wraps */
+#define AS_RQ2_WRAP 0x02 /* request 2 wraps */
+ unsigned wrap = 0; /* bit mask: requests behind the disk head? */
+
const sector_t maxback = MAXBACK;
if (arq1 == NULL || arq1 == arq2)
@@ -486,40 +489,48 @@
d1 = s1 - last;
else if (s1+maxback >= last)
d1 = (last - s1)*BACK_PENALTY;
- else {
- r1_wrap = 1;
- d1 = 0; /* shut up, gcc */
- }
+ else
+ wrap |= AS_RQ1_WRAP;
if (s2 >= last)
d2 = s2 - last;
else if (s2+maxback >= last)
d2 = (last - s2)*BACK_PENALTY;
- else {
- r2_wrap = 1;
- d2 = 0;
- }
+ else
+ wrap |= AS_RQ2_WRAP;
/* Found required data */
- if (!r1_wrap && r2_wrap)
- return arq1;
- else if (!r2_wrap && r1_wrap)
- return arq2;
- else if (r1_wrap && r2_wrap) {
- /* both behind the head */
- if (s1 <= s2)
+
+ /*
+ * By doing switch() on the bit mask "wrap" we avoid having to
+ * check two variables for all permutations: --> faster!
+ */
+ switch (wrap) {
+ case 0: /* arq1 and arq2 not wrapped */
+ if (d1 < d2)
return arq1;
- else
+ else if (d2 < d1)
return arq2;
- }
+ else {
+ if (s1 >= s2)
+ return arq1;
+ else
+ return arq2;
+ }
- /* Both requests in front of the head */
- if (d1 < d2)
+ case AS_RQ2_WRAP:
return arq1;
- else if (d2 < d1)
+ case AS_RQ1_WRAP:
return arq2;
- else {
- if (s1 >= s2)
+ case (AS_RQ1_WRAP|AS_RQ2_WRAP): /* both arqs wrapped */
+ default:
+ /*
+ * Since both rqs are wrapped,
+ * start with the one that's further behind head
+ * (--> only *one* back seek required),
+ * since back seek takes more time than forward.
+ */
+ if (s1 <= s2)
return arq1;
else
return arq2;
^ permalink raw reply
* Re: Question regarding to store file system metadata in database
From: Ming Zhang @ 2006-03-19 18:26 UTC (permalink / raw)
To: Xin Zhao; +Cc: mikado4vn, linux-kernel, linux-fsdevel
In-Reply-To: <4ae3c140603191011r7b68f4aale01238202656d122@mail.gmail.com>
no. i have no such statistics. also people always want it to be faster,
so it is never enough.
from another point of view, if such fs is used by a mail server, large #
of file create/close/modify will be vital for it. 300/s is not enough
for a busy mail server of course.
database based file system will be useful for archiving. for heavy
online use? not sure.
also will a database based fs too be too complex while all benefits
brought by db can be brought by add-on utilities? find and grep do not
fit u bill?
ming
On Sun, 2006-03-19 at 13:11 -0500, Xin Zhao wrote:
> Do you have any statistics on how many metadata accesses are required
> for a heavy load file system? I don't have on in hand, but
> intuitively I think 300 per second should be enough. If storing
> metadata in database will not hit the file system performance, plus
> database allows flexible file searching, the database-based file
> system might not be a bad idea. :)
>
> Xin
>
> On 3/19/06, Ming Zhang <mingz@ele.uri.edu> wrote:
> > database can reside on a raw block device.
> >
> > but 300 metadata iops is not that fast. ;)
> >
> > ming
> >
> > On Sun, 2006-03-19 at 12:48 -0500, Xin Zhao wrote:
> > > well, the database could reside on another file system. So the
> > > database based file system could be a secondary file system but
> > > provide more features and better performance. I am not saying that
> > > database-based file system must be the only filesystem on the system.
> > >
> > > On 3/19/06, Mikado <mikado4vn@gmail.com> wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > Where is that database located, on other filesystem or on database-based
> > > > filesystem?
> > > >
> > > > Xin Zhao wrote:
> > > > > I was wondering why only few file system uses database to store file
> > > > > system metadata. Here, metadata primarily refers to directory entries.
> > > > > For example, one can setup a database to store file pathname, its
> > > > > inode number, and some extended attribution. File pathname can be used
> > > > > as primary key. As such, we can achieve pathname to inode mapping as
> > > > > well as many other features such as fast search and extended file
> > > > > attribute management. In contrast, storing file system entries in
> > > > > directory files may result in slow dentry search. I guess that's why
> > > > > ReiserFS and some other file systems proposed to use B+ tree like
> > > > > strucutre to manage file entries. But why not simple use database to
> > > > > provide the same feature? DB has been heavily optimized to provide
> > > > > fast search and should be good at managing metadata.
> > > > >
> > > > > I guess one concern about this idea is performance impact caused by
> > > > > database system. I ran a test on a mysql database: I inserted about
> > > > > 1.2 million such kind of records into an initially empty mysql
> > > > > database. Average insertion rate is about 300 entries per second,
> > > > > which is fast enough to handle normal file system burden, I think. I
> > > > > haven't try the query speed, but I believe it should be fast enough
> > > > > too (maybe I am wrong, if so, please point that out.).
> > > > >
> > > > > Then I am a little curious why only few people use database to store
> > > > > file system metadata, although I know WinFS plans to use database to
> > > > > manage metadata. I guess one reason is that it is difficult for kernel
> > > > > based file system driver to access database. But this could be
> > > > > addressed by using efficient kernel/user communication mechanism.
> > > > > Another reason could be the worry about database system. If database
> > > > > system crashes, file system will stop functioning too. However, the
> > > > > feature needed by file system is really a small part of database
> > > > > system, A reduced database system should be sufficient to provide this
> > > > > feature and be stable enough to support a file system.
> > > > >
> > > > > Can someone point out more issues that could become obstables to using
> > > > > database to manage metadata for a file system?
> > > > >
> > > > > Many thanks!
> > > > > Xin
> > > > > -
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > > the body of a message to majordomo@vger.kernel.org
> > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > > Please read the FAQ at http://www.tux.org/lkml/
> > > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.2.1 (GNU/Linux)
> > > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > > >
> > > > iD8DBQFEHOceNWc9T2Wr2JcRAsKKAJ9t1fRZ1xczAaeruDUqTNeLMcGuiwCfeTNt
> > > > 31pFUK79Q7BE1AptbmNqr9Q=
> > > > =LbiF
> > > > -----END PGP SIGNATURE-----
> > > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
^ permalink raw reply
* Re: [PATCH 001/001] PCI: PCI quirk for Asus A8V and A8V Deluxe motherboards
From: Andras Mantia @ 2006-03-19 18:18 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <yw1xbqw2z50o.fsf@agrajag.inprovide.com>
Måns Rullgård wrote:
> OK, I just used the simpler (and newer) of the two versions that were
> posted, and modified as suggested by someone. Does my version work on
> your machine?
I did not try it, but because of the code and the outputs I got when I tried
to find the problem I'm sure it would work.
>> Anyway, my suggestion remains, that the
>> + if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
>> + return;
>> + if (dev->device != PCI_DEVICE_ID_VIA_8237)
>> + return;
>>
>> might be not needed at all as it is not ASUS specific.
>
> Doesn't it depend on the BIOS? My BIOS lets me choose between
> "automatic" and "disabled" for the onboard sound.
I don't see how that setting could change the device ID or the vendor ID. As
I understood the above code will simply not try to enable the sound device
if:
a) the vendor is not ASUSTEK
b) the device is not ID is not PCI_DEVICE_ID_VIA_8237
For a) it means that an MSI/Epox/whatever board with the same VIA chipset
and the same problem will not be handled. For b) see my previous comment
(and your concerns).
Well, it would be nice if a kernel developer could comment on it, or simply
include the right version in some upcoming release. ;-)
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
^ permalink raw reply
* Re: Question regarding to store file system metadata in database
From: Xin Zhao @ 2006-03-19 18:11 UTC (permalink / raw)
To: mingz; +Cc: mikado4vn, linux-kernel, linux-fsdevel
In-Reply-To: <1142791121.31358.21.camel@localhost.localdomain>
Do you have any statistics on how many metadata accesses are required
for a heavy load file system? I don't have on in hand, but
intuitively I think 300 per second should be enough. If storing
metadata in database will not hit the file system performance, plus
database allows flexible file searching, the database-based file
system might not be a bad idea. :)
Xin
On 3/19/06, Ming Zhang <mingz@ele.uri.edu> wrote:
> database can reside on a raw block device.
>
> but 300 metadata iops is not that fast. ;)
>
> ming
>
> On Sun, 2006-03-19 at 12:48 -0500, Xin Zhao wrote:
> > well, the database could reside on another file system. So the
> > database based file system could be a secondary file system but
> > provide more features and better performance. I am not saying that
> > database-based file system must be the only filesystem on the system.
> >
> > On 3/19/06, Mikado <mikado4vn@gmail.com> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Where is that database located, on other filesystem or on database-based
> > > filesystem?
> > >
> > > Xin Zhao wrote:
> > > > I was wondering why only few file system uses database to store file
> > > > system metadata. Here, metadata primarily refers to directory entries.
> > > > For example, one can setup a database to store file pathname, its
> > > > inode number, and some extended attribution. File pathname can be used
> > > > as primary key. As such, we can achieve pathname to inode mapping as
> > > > well as many other features such as fast search and extended file
> > > > attribute management. In contrast, storing file system entries in
> > > > directory files may result in slow dentry search. I guess that's why
> > > > ReiserFS and some other file systems proposed to use B+ tree like
> > > > strucutre to manage file entries. But why not simple use database to
> > > > provide the same feature? DB has been heavily optimized to provide
> > > > fast search and should be good at managing metadata.
> > > >
> > > > I guess one concern about this idea is performance impact caused by
> > > > database system. I ran a test on a mysql database: I inserted about
> > > > 1.2 million such kind of records into an initially empty mysql
> > > > database. Average insertion rate is about 300 entries per second,
> > > > which is fast enough to handle normal file system burden, I think. I
> > > > haven't try the query speed, but I believe it should be fast enough
> > > > too (maybe I am wrong, if so, please point that out.).
> > > >
> > > > Then I am a little curious why only few people use database to store
> > > > file system metadata, although I know WinFS plans to use database to
> > > > manage metadata. I guess one reason is that it is difficult for kernel
> > > > based file system driver to access database. But this could be
> > > > addressed by using efficient kernel/user communication mechanism.
> > > > Another reason could be the worry about database system. If database
> > > > system crashes, file system will stop functioning too. However, the
> > > > feature needed by file system is really a small part of database
> > > > system, A reduced database system should be sufficient to provide this
> > > > feature and be stable enough to support a file system.
> > > >
> > > > Can someone point out more issues that could become obstables to using
> > > > database to manage metadata for a file system?
> > > >
> > > > Many thanks!
> > > > Xin
> > > > -
> > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > Please read the FAQ at http://www.tux.org/lkml/
> > > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.2.1 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > >
> > > iD8DBQFEHOceNWc9T2Wr2JcRAsKKAJ9t1fRZ1xczAaeruDUqTNeLMcGuiwCfeTNt
> > > 31pFUK79Q7BE1AptbmNqr9Q=
> > > =LbiF
> > > -----END PGP SIGNATURE-----
> > >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [Patch 5 of 8] Add the __stack_chk_fail() function
From: Arjan van de Ven @ 2006-03-19 18:06 UTC (permalink / raw)
To: Nix; +Cc: linux-kernel
In-Reply-To: <878xr62u70.fsf@hades.wkstn.nix>
Nix wrote:
> On 17 Mar 2006, Arjan van de Ven wrote:
>> GCC emits a call to a __stack_chk_fail() function when the cookie is not
>> matching the expected value. Since this is a bad security issue; lets panic
>> the kernel
>
> This turns even minor buffer overflows into complete denials of service.
only those who otherwise would get to the return address. So it turns a "own the machine" into a panic.
Not a "no side effects" thing....
> If we're running in process context and the process is currently
> killable it might make more sense to printk() a message and zap the
> process; that way we only halt whatever service it is the attacker
> hit us through.
maybe. The big question is if you can still trust the machine. That is highly questionable...
(and to kill the process you again need to trust bits of the stack, to get to current for example;
and you just found that the stack was compromised)
^ permalink raw reply
* Re: saa7111.c patch
From: Ronald S. Bultje @ 2006-03-19 17:52 UTC (permalink / raw)
To: Martin Samuelsson; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20060319114124.11d4fa9d.sam@home.se>
Hi,
On Sun, 19 Mar 2006, Martin Samuelsson wrote:
> When grabbing composite video with Iomega Buz, the stock driver will
> prevent grabbing from the same input twice in a row, forcing the user
> to switch inputs before anything useful can be grabbed again. It is
> caused by some optimization code in the input selection parts, and
> triggered by the saa7111_command() executing cmd 0. The attached patch
> will remedy this by disabling cmd 0 altogether; a fix that has no found
> negative effects on the rest of the code. In fact, saa7110.c does the
> exact same thing.
I second this patch, can you please add it to your tree? Thanks,
Ronald
^ permalink raw reply
* Re: [RFC][PATCH 1/6] prepare sysctls for containers
From: Eric W. Biederman @ 2006-03-19 15:54 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, serue, frankeh, clg, Sam Vilain
In-Reply-To: <20060307024505.GA15713@MAIL.13thfloor.at>
Herbert Poetzl <herbert@13thfloor.at> writes:
> sure, basically we have two cases which interact
> with userspace: the read and the write case.
>
> for the read case, we want something which gives
> us the 'virtualized' view, which might often be
> the same as the host gets, where for the write
> case it is usually not that simple, as we might
> not want a context to write to 'world' stuff
>
> so, having two different functions here, or one
> which gets passed the direction, might be much
> simpler to adjust in many cases than adding more
> and more structures ... but YMMV
I'm not convinced either way yet but my gut feel is that
the use case for get/put functions is incomplete permission
checks on various sysctls.
If that is the fixing the permission checks looks like the
right thing to do.
Eric
^ permalink raw reply
* Re: [PATCH 001/001] PCI: PCI quirk for Asus A8V and A8V Deluxe motherboards
From: Måns Rullgård @ 2006-03-19 18:03 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <dvk4tv$9j9$1@sea.gmane.org>
Andras Mantia <amantia@kde.org> writes:
> Måns Rullgård wrote:
>
>> Hmm, we seem to be using different patches. Here's what I'm using:
>>
> Oh, yeah. I used the original one posted here (actually I get from
> some -mm patch collection IIRC, I don't remember from which one).
OK, I just used the simpler (and newer) of the two versions that were
posted, and modified as suggested by someone. Does my version work on
your machine?
> Anyway, my suggestion remains, that the
> + if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
> + return;
> + if (dev->device != PCI_DEVICE_ID_VIA_8237)
> + return;
>
> might be not needed at all as it is not ASUS specific.
Doesn't it depend on the BIOS? My BIOS lets me choose between
"automatic" and "disabled" for the onboard sound.
> I don't understand the second if, as (from my limited knowledge) it
> seems that
>
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
> asus_hides_ac97_lpc );
>
> already means the function will be called only for devices with PCI id
> PCI_DEVICE_ID_VIA_8237 .
That struck me too.
--
Måns Rullgård
mru@inprovide.com
^ permalink raw reply
* Re: Idea: Automatic binary driver compiling system
From: Nix @ 2006-03-19 18:02 UTC (permalink / raw)
To: Lee Revell; +Cc: Benjamin Bach, linux-kernel
In-Reply-To: <1142620509.25258.53.camel@mindpipe>
On 17 Mar 2006, Lee Revell murmured woefully:
> On Fri, 2006-03-17 at 19:00 +0100, Benjamin Bach wrote:
>> First off: I'm new on this list. I'm also new at starting projects.
>> Anyways, I've decided on this idea for my first year computer science
>> project. I have three months to set it off and definitely the whole
>> thing would be released into the world afterwards.
>>
>> Second: I don't want opinions on the issue of making it easier for
>> companies to create binary (pre-compiled) drivers. Yes, we all want more
>> open source drivers. Of course.
>
> Then let's end the thread here because this is the crux of ther issue -
> no one WANTS it to be easier for vendors to ship binary drivers.
Well, this could be useful for distributors, too, except that distributors
already have mechanisms for autobuilding kernels and modules.
--
`Come now, you should know that whenever you plan the duration of your
unplanned downtime, you should add in padding for random management
freakouts.'
^ permalink raw reply
* Re: Question regarding to store file system metadata in database
From: Ming Zhang @ 2006-03-19 17:58 UTC (permalink / raw)
To: Xin Zhao; +Cc: mikado4vn, linux-kernel, linux-fsdevel
In-Reply-To: <4ae3c140603190948s4fcd135er370a15003a0143a8@mail.gmail.com>
database can reside on a raw block device.
but 300 metadata iops is not that fast. ;)
ming
On Sun, 2006-03-19 at 12:48 -0500, Xin Zhao wrote:
> well, the database could reside on another file system. So the
> database based file system could be a secondary file system but
> provide more features and better performance. I am not saying that
> database-based file system must be the only filesystem on the system.
>
> On 3/19/06, Mikado <mikado4vn@gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Where is that database located, on other filesystem or on database-based
> > filesystem?
> >
> > Xin Zhao wrote:
> > > I was wondering why only few file system uses database to store file
> > > system metadata. Here, metadata primarily refers to directory entries.
> > > For example, one can setup a database to store file pathname, its
> > > inode number, and some extended attribution. File pathname can be used
> > > as primary key. As such, we can achieve pathname to inode mapping as
> > > well as many other features such as fast search and extended file
> > > attribute management. In contrast, storing file system entries in
> > > directory files may result in slow dentry search. I guess that's why
> > > ReiserFS and some other file systems proposed to use B+ tree like
> > > strucutre to manage file entries. But why not simple use database to
> > > provide the same feature? DB has been heavily optimized to provide
> > > fast search and should be good at managing metadata.
> > >
> > > I guess one concern about this idea is performance impact caused by
> > > database system. I ran a test on a mysql database: I inserted about
> > > 1.2 million such kind of records into an initially empty mysql
> > > database. Average insertion rate is about 300 entries per second,
> > > which is fast enough to handle normal file system burden, I think. I
> > > haven't try the query speed, but I believe it should be fast enough
> > > too (maybe I am wrong, if so, please point that out.).
> > >
> > > Then I am a little curious why only few people use database to store
> > > file system metadata, although I know WinFS plans to use database to
> > > manage metadata. I guess one reason is that it is difficult for kernel
> > > based file system driver to access database. But this could be
> > > addressed by using efficient kernel/user communication mechanism.
> > > Another reason could be the worry about database system. If database
> > > system crashes, file system will stop functioning too. However, the
> > > feature needed by file system is really a small part of database
> > > system, A reduced database system should be sufficient to provide this
> > > feature and be stable enough to support a file system.
> > >
> > > Can someone point out more issues that could become obstables to using
> > > database to manage metadata for a file system?
> > >
> > > Many thanks!
> > > Xin
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2.1 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFEHOceNWc9T2Wr2JcRAsKKAJ9t1fRZ1xczAaeruDUqTNeLMcGuiwCfeTNt
> > 31pFUK79Q7BE1AptbmNqr9Q=
> > =LbiF
> > -----END PGP SIGNATURE-----
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch 5 of 8] Add the __stack_chk_fail() function
From: Nix @ 2006-03-19 17:57 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
In-Reply-To: <1142612087.3033.110.camel@laptopd505.fenrus.org>
On 17 Mar 2006, Arjan van de Ven wrote:
> GCC emits a call to a __stack_chk_fail() function when the cookie is not
> matching the expected value. Since this is a bad security issue; lets panic
> the kernel
This turns even minor buffer overflows into complete denials of service.
If we're running in process context and the process is currently
killable it might make more sense to printk() a message and zap the
process; that way we only halt whatever service it is the attacker
hit us through.
(I agree that this is much-needed: I'm doing the rough equivalent in UML
right now, where it's a good bit simpler, but having it for the real
kernel on bare metal will be great!)
--
`Come now, you should know that whenever you plan the duration of your
unplanned downtime, you should add in padding for random management
freakouts.'
^ permalink raw reply
* Re: Question regarding to store file system metadata in database
From: Xin Zhao @ 2006-03-19 17:48 UTC (permalink / raw)
To: mikado4vn; +Cc: linux-kernel, linux-fsdevel
In-Reply-To: <441CE71E.5090503@gmail.com>
well, the database could reside on another file system. So the
database based file system could be a secondary file system but
provide more features and better performance. I am not saying that
database-based file system must be the only filesystem on the system.
On 3/19/06, Mikado <mikado4vn@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Where is that database located, on other filesystem or on database-based
> filesystem?
>
> Xin Zhao wrote:
> > I was wondering why only few file system uses database to store file
> > system metadata. Here, metadata primarily refers to directory entries.
> > For example, one can setup a database to store file pathname, its
> > inode number, and some extended attribution. File pathname can be used
> > as primary key. As such, we can achieve pathname to inode mapping as
> > well as many other features such as fast search and extended file
> > attribute management. In contrast, storing file system entries in
> > directory files may result in slow dentry search. I guess that's why
> > ReiserFS and some other file systems proposed to use B+ tree like
> > strucutre to manage file entries. But why not simple use database to
> > provide the same feature? DB has been heavily optimized to provide
> > fast search and should be good at managing metadata.
> >
> > I guess one concern about this idea is performance impact caused by
> > database system. I ran a test on a mysql database: I inserted about
> > 1.2 million such kind of records into an initially empty mysql
> > database. Average insertion rate is about 300 entries per second,
> > which is fast enough to handle normal file system burden, I think. I
> > haven't try the query speed, but I believe it should be fast enough
> > too (maybe I am wrong, if so, please point that out.).
> >
> > Then I am a little curious why only few people use database to store
> > file system metadata, although I know WinFS plans to use database to
> > manage metadata. I guess one reason is that it is difficult for kernel
> > based file system driver to access database. But this could be
> > addressed by using efficient kernel/user communication mechanism.
> > Another reason could be the worry about database system. If database
> > system crashes, file system will stop functioning too. However, the
> > feature needed by file system is really a small part of database
> > system, A reduced database system should be sufficient to provide this
> > feature and be stable enough to support a file system.
> >
> > Can someone point out more issues that could become obstables to using
> > database to manage metadata for a file system?
> >
> > Many thanks!
> > Xin
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEHOceNWc9T2Wr2JcRAsKKAJ9t1fRZ1xczAaeruDUqTNeLMcGuiwCfeTNt
> 31pFUK79Q7BE1AptbmNqr9Q=
> =LbiF
> -----END PGP SIGNATURE-----
>
^ permalink raw reply
* Re: OOPS: 2.6.16-rc6 cpufreq_conservative
From: Linus Torvalds @ 2006-03-19 17:43 UTC (permalink / raw)
To: Paul Jackson
Cc: akpm, kernel-stuff, linux-kernel, alex-kernel, jun.nakajima,
davej
In-Reply-To: <20060318210840.e7156b6b.pj@sgi.com>
On Sat, 18 Mar 2006, Paul Jackson wrote:
>
> If find_first_bit and find_next_bit suck so bad, then why just fix
> their use in the for_each_cpu_mask(). How about the other uses?
find_first_bit/find_next_bit don't actually suck. They're perfectly
efficient for large bitmaps, which is what they were designed for (ie they
were written for doing the free-block/inode bitmaps for minixfs
originally).
In other words, they are meant for bitmaps of _thousands_ of bits, and
for potentially sparse bitmaps.
Now, the CPU masks _can_ be large too, but commonly they are not. In this
example, the "bitmap" was exactly two bits: cpu 0 and cpu 1. Using a
complex "find_next_bit" for something like that is just overkill.
> And if we fix the cpu loop to the API Linus suggests, we should do the
> same with the node loops
Yes. Almost ever "for_each_xyzzy" tends to be more easily written as a
macro if we also have a ending condition.
> And for those of us with too many CPUs, how about something like
> (totally untested and probably totally bogus):
>
> #if NR_CPUS <= BITS_IN_LONG
> ... as per Linus, shifting a mask right ...
> #else
> #define for_each_cpu_mask(cpu, mask)
> { for (cpu = 0; cpu < NR_CPUS; cpu++) {
> if (!(test_bit(cpu, mask))
> continue;
> #endif
>
> #define end_for_each_cpu_mask } }
Yes, except you'd probably be better off with testing whole words at a
time, since a large NR_CPUs can often be because somebody wanted to
support 256 CPU machines, and then used the same binary on a 8-way setup.
That would most helpfully be done with a double loop (outer one iterating
over the bitmask words, inner one over the bits), but then it's hard to
make "break" do the right thing inside the loop.
Linus
^ permalink raw reply
* Re: [PATCH 001/001] PCI: PCI quirk for Asus A8V and A8V Deluxe motherboards
From: Andras Mantia @ 2006-03-19 17:38 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <yw1xslpez928.fsf@agrajag.inprovide.com>
Måns Rullgård wrote:
> Hmm, we seem to be using different patches. Here's what I'm using:
>
Oh, yeah. I used the original one posted here (actually I get from some -mm
patch collection IIRC, I don't remember from which one).
Anyway, my suggestion remains, that the
+ if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+ return;
+ if (dev->device != PCI_DEVICE_ID_VIA_8237)
+ return;
might be not needed at all as it is not ASUS specific. I don't understand
the second if, as (from my limited knowledge) it seems that
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
asus_hides_ac97_lpc );
already means the function will be called only for devices with PCI id
PCI_DEVICE_ID_VIA_8237 .
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
^ permalink raw reply
* Re: OOPS: 2.6.16-rc6 cpufreq_conservative
From: Alexander Clouter @ 2006-03-19 17:34 UTC (permalink / raw)
To: Parag Warudkar
Cc: Andrew Morton, Linus Torvalds, linux-kernel, jun.nakajima, davej
In-Reply-To: <200603190906.25174.kernel-stuff@comcast.net>
[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]
Hi,
Parag Warudkar <kernel-stuff@comcast.net> [20060319 09:06:25 -0500]:
>
> The codebase already seems identical to ondemand - Are your patches in
> 2.6.16-rc6 or -mm? If they are - let me know which. If you posted them but
> they haven't yet made it into either -mm or mainline can you please post
> links to all your patches please? I can test them.
>
Well I submitted them back on 2006-02-24:
http://marc.theaimsgroup.com/?l=linux-kernel&m=114079151404567&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=114079151425558&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=114079151417220&w=2
It has been pointed out I did forget to CC the cpufreq folk, so thats
completely my fault; I thought I had. :-/
> Why do we even have conservative and ondemand as two separate modules given
> they share huge amount of code - perhaps make conservative an optional
> behaviour of ondemand or alteast make a common lib which both use?
>
Originally the 'conservative' feature was just a sysfs flag that could be set
however it was rejected for a number of reasons; one of them quite rightly,
we have a modular system that can take stacks of cpufreq governors so lets
use that :)
Also, more importantly, bugs in my bits do not affect the original author.
It makes more sense to keep things this way as the internal code then does
not need a bunch of if{}'s scattered around and also I have a number of extra
sysfs files to tweak which would either do nothing in 'ondemand' mode or have
to be magically created and destroyed.
Either way, its probably neater this way and its *my* duty to make sure
anything changing for ondemand is considered for conservative. If you look
at a lot of the userland tools that have come out, it would be a pain to have
them consider the exception class of handling the combined
ondemand/conservative.
Breaking out the thing into a library probably would be awkward as all the
similar code is actually inline in functions, putting that in a seperate file
would be pointless. Hopefully when you apply my patches and then do a diff
between the ondemand and conservative governors you will see what I mean.
Cheers
Alex
--
________________________________________
/ Fortune finishes the great quotations, \
| #3 |
| |
| Birds of a feather flock to a newly |
\ washed car. /
----------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] v9fs: update license boilerplate
From: Eric Van Hensbergen @ 2006-03-19 17:02 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, v9fs-developer, ericvh
Subject: [PATCH] v9fs: update license boilerplate
Update license boilerplate to specify GPLv2 and remove
the (at your option clause). This change was agreed to by
all the copyright holders (approvals can be found on
v9fs-developer mailing list).
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
---
fs/9p/9p.c | 5 ++---
fs/9p/9p.h | 5 ++---
fs/9p/conv.c | 5 ++---
fs/9p/conv.h | 5 ++---
fs/9p/debug.h | 5 ++---
fs/9p/error.c | 5 ++---
fs/9p/error.h | 5 ++---
fs/9p/fcprint.c | 5 ++---
fs/9p/fid.c | 5 ++---
fs/9p/fid.h | 5 ++---
fs/9p/mux.c | 5 ++---
fs/9p/mux.h | 5 ++---
fs/9p/trans_fd.c | 6 ++----
fs/9p/transport.h | 5 ++---
fs/9p/v9fs.c | 5 ++---
fs/9p/v9fs.h | 5 ++---
fs/9p/v9fs_vfs.h | 5 ++---
fs/9p/vfs_addr.c | 5 ++---
fs/9p/vfs_dentry.c | 5 ++---
fs/9p/vfs_dir.c | 5 ++---
fs/9p/vfs_file.c | 5 ++---
fs/9p/vfs_inode.c | 5 ++---
fs/9p/vfs_super.c | 5 ++---
23 files changed, 46 insertions(+), 70 deletions(-)
8c9712b48e4f886b34eb8c6104ed879204d2868e
diff --git a/fs/9p/9p.c b/fs/9p/9p.c
index 7d97e9f..1d7ef3a 100644
--- a/fs/9p/9p.c
+++ b/fs/9p/9p.c
@@ -8,9 +8,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/9p.h b/fs/9p/9p.h
index 5286b24..82b076a 100644
--- a/fs/9p/9p.h
+++ b/fs/9p/9p.h
@@ -8,9 +8,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/conv.c b/fs/9p/conv.c
index 8ca3cc5..758dbcd 100644
--- a/fs/9p/conv.c
+++ b/fs/9p/conv.c
@@ -8,9 +8,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/conv.h b/fs/9p/conv.h
index dfb3912..8f5c230 100644
--- a/fs/9p/conv.h
+++ b/fs/9p/conv.h
@@ -8,9 +8,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/debug.h b/fs/9p/debug.h
index ff54a7b..4228c0b 100644
--- a/fs/9p/debug.h
+++ b/fs/9p/debug.h
@@ -5,9 +5,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/error.c b/fs/9p/error.c
index e4b6f8f..981fe8e 100644
--- a/fs/9p/error.c
+++ b/fs/9p/error.c
@@ -11,9 +11,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/error.h b/fs/9p/error.h
index a9794e8..5f3ca52 100644
--- a/fs/9p/error.h
+++ b/fs/9p/error.h
@@ -12,9 +12,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/fcprint.c b/fs/9p/fcprint.c
index fc8a984..583e827 100644
--- a/fs/9p/fcprint.c
+++ b/fs/9p/fcprint.c
@@ -6,9 +6,8 @@
* Copyright (C) 2005 by Latchesar Ionkov <lucho@ionkov.net>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index c4d13bf..b7608af 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -4,9 +4,8 @@
* Copyright (C) 2005, 2006 by Eric Van Hensbergen <ericvh@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/fid.h b/fs/9p/fid.h
index 1fc2dd0..aa974d6 100644
--- a/fs/9p/fid.h
+++ b/fs/9p/fid.h
@@ -4,9 +4,8 @@
* Copyright (C) 2005 by Eric Van Hensbergen <ericvh@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/mux.c b/fs/9p/mux.c
index d9a748e..d3785f8 100644
--- a/fs/9p/mux.c
+++ b/fs/9p/mux.c
@@ -7,9 +7,8 @@
* Copyright (C) 2004-2005 by Latchesar Ionkov <lucho@ionkov.net>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/mux.h b/fs/9p/mux.h
index 9473b84..6097a4e 100644
--- a/fs/9p/mux.h
+++ b/fs/9p/mux.h
@@ -7,9 +7,8 @@
* Copyright (C) 2004 by Eric Van Hensbergen <ericvh@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/trans_fd.c b/fs/9p/trans_fd.c
index 8029844..94e0a7f 100644
--- a/fs/9p/trans_fd.c
+++ b/fs/9p/trans_fd.c
@@ -7,12 +7,10 @@
* Copyright (C) 2004-2005 by Latchesar Ionkov <lucho@ionkov.net>
* Copyright (C) 2004-2005 by Eric Van Hensbergen <ericvh@gmail.com>
* Copyright (C) 1997-2002 by Ron Minnich <rminnich@sarnoff.com>
- * Copyright (C) 1995, 1996 by Olaf Kirch <okir@monad.swb.de>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/transport.h b/fs/9p/transport.h
index 91fcdb9..b38a4b8 100644
--- a/fs/9p/transport.h
+++ b/fs/9p/transport.h
@@ -7,9 +7,8 @@
* Copyright (C) 2004 by Eric Van Hensbergen <ericvh@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 321989a..e49e7d1 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -7,9 +7,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/v9fs.h b/fs/9p/v9fs.h
index 9f63ab8..c134d10 100644
--- a/fs/9p/v9fs.h
+++ b/fs/9p/v9fs.h
@@ -5,9 +5,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/v9fs_vfs.h b/fs/9p/v9fs_vfs.h
index a759278..43c9f7d 100644
--- a/fs/9p/v9fs_vfs.h
+++ b/fs/9p/v9fs_vfs.h
@@ -5,9 +5,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
index 8100fb5..efda46f 100644
--- a/fs/9p/vfs_addr.c
+++ b/fs/9p/vfs_addr.c
@@ -7,9 +7,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/vfs_dentry.c b/fs/9p/vfs_dentry.c
index 12c9cc9..2c42f75 100644
--- a/fs/9p/vfs_dentry.c
+++ b/fs/9p/vfs_dentry.c
@@ -7,9 +7,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
index cd5eeb0..766f11f 100644
--- a/fs/9p/vfs_dir.c
+++ b/fs/9p/vfs_dir.c
@@ -7,9 +7,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 1144d59..59e7441 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -7,9 +7,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 588d0d2..d574d73 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -7,9 +7,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c
index d05318f..083ed5a 100644
--- a/fs/9p/vfs_super.c
+++ b/fs/9p/vfs_super.c
@@ -8,9 +8,8 @@
* Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
*
* This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
--
1.1.0
^ permalink raw reply related
* Re: /dev/stderr gets unlinked 8]
From: Joshua Hudson @ 2006-03-19 16:57 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <E1FKmO8-000303-Ve@be1.lrz>
On 3/18/06, Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> wrote:
> linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
> > On Fri, 17 Mar 2006, Jan Engelhardt wrote:
>
> >> If not, you could write an LSM that prohibits unlinking /dev/stderr.
>
> > That symlink isn't even used -- at least by any sane program!
> > I don't have a clue why these things were created and what they
> > were for. The objects stdin, stdout, and stderr, are 'C' runtime
> > library pointers to opaque types associated with the file descriptors,
> > STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO. The presence of
> > these bogus sym-links in /dev represent some kind of obfuscation
> > and have no value except to confuse (or identify a RedHat distribution).
>
> Think about portable shell scripts. I remember /dev/std* longer than /proc.
They're from BSD (where they are real devices, with a major & minor number).
^ permalink raw reply
* Re: [PATCH 001/001] PCI: PCI quirk for Asus A8V and A8V Deluxe motherboards
From: Måns Rullgård @ 2006-03-19 16:35 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <dvjsa6$i92$1@sea.gmane.org>
Andras Mantia <amantia@kde.org> writes:
> Måns Rullgård wrote:
>
>> This is the interesting bit. Curiously enough, it is exactly the same
>> as mine. I can't see any reason why it shouldn't match on your board.
>>
>> Try sticking some printk()s in there and find out what values are
>> actually seen.
>
> I found why it didn't work on my PC before. I wrote that I not only enabled
> for every PCI id, but removed the following check:
>
> if (likely(!asus_hides_ac97))
> return;
>
> This was the bit which made it work. After putting some debugging
> information it turned out that asus_hides_ac97_lpc was called *before*
> asus_hides_ac97_device, so the asus_hides_ac97 remained 0 in that check.
>
> As far as I know this problem appears on all VT8237 boards (I found in
> several forums), I suggest to completely drop the asus_hides_ac97_device
> function and the above if clause.
Hmm, we seem to be using different patches. Here's what I'm using:
--- drivers/pci/quirks.c.orig 2006-01-03 03:21:10.000000000 +0000
+++ drivers/pci/quirks.c 2006-03-19 16:34:02.021338158 +0000
@@ -1074,6 +1074,33 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_963, quirk_sis_96x_smbus );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC, quirk_sis_96x_smbus );
+/*
+ * On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
+ * and MC97 modem controller are disabled when a second PCI soundcard is
+ * present. This patch, tweaking the VT8237 ISA bridge, enables them.
+ * -- bjd
+ */
+static void __init asus_hides_ac97_lpc(struct pci_dev *dev)
+{
+ u8 val;
+
+ if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+ return;
+ if (dev->device != PCI_DEVICE_ID_VIA_8237)
+ return;
+
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0) {
+ pci_write_config_byte(dev, 0x50, val & (~0xc0));
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0)
+ printk(KERN_INFO "PCI: Failed to enable onboard AC97/MC97 devices: 0x%x\n", val);
+ else
+ printk(KERN_INFO "PCI: enabled onboard AC97/MC97 devices\n");
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237, asus_hides_ac97_lpc );
+
#ifdef CONFIG_X86_IO_APIC
static void __init quirk_alder_ioapic(struct pci_dev *pdev)
{
--
Måns Rullgård
mru@inprovide.com
^ permalink raw reply
* Re: Idea: Automatic binary driver compiling system
From: Sander @ 2006-03-19 16:30 UTC (permalink / raw)
To: Benjamin Bach; +Cc: Lee Revell, linux-kernel
In-Reply-To: <441C213A.3000404@overtag.dk>
Benjamin Bach wrote (ao):
> Linux get's better hardware support
With the help of binary drivers? Not likely. The smart people on this
list can't help for example.
> As of now Linux won't force vendors into creating open source drivers.
> That'd be like a small dog barking.
Well, as a customer you can put your money where your mouth is, and
simply buy other hardware. That is a way of forcing, or at least
stimulating the market.
As a kernel hacker you can choose to reverse engineer.
Btw, read this thread and tell me if you still agree that binary drivers
and depending on a company are a good thing:
http://forum.matrox.com/mga/viewtopic.php?t=19208&sid=724d14d42714800f9d13ee6286f37f0b
Kind regards, Sander
--
Humilis IT Services and Solutions
http://www.humilis.net
^ permalink raw reply
* [ANNOUNCE] Linux-2.4.32-hf32.3
From: Willy Tarreau @ 2006-03-19 16:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Marcelo Tosatti, Grant Coady
Hi,
here goes the third hotfix for 2.4.32 and older kernels. There are 12
new fixes (it's been one month and a half since hf32.2). Particularly,
you will find a fix for CVE-2005-3180 and another one for a local DoS
affecting ELF on Intel x86_64. Exceptionnaly, a fix has been brought
to two drivers, orinoco (which was the subject of the CVE) and E1000
which can crash the kernel by simply moving the cable. Others are
fixes for build and minor bugs.
The full changelog is appended to this mail.
Please use the links below to download it :
hotfixes home : http://linux.exosec.net/kernel/2.4-hf/
last version : http://linux.exosec.net/kernel/2.4-hf/LATEST/LATEST/
RSS feed : http://linux.exosec.net/kernel/hf.xml
build results : http://bugsplatter.mine.nu/test/linux-2.4/ (Grant's site)
Also, I've moved the project to GIT and new patches will be available here
waiting for next release :
GIT: http://w.ods.org/kernel/2.4/patches-2.4-hf.git/
GITWEB: http://w.ods.org/git/?p=patches-2.4-hf.git;a=summary
Regards,
Willy
Changelog from 2.4.32-hf32.2 to 2.4.32-hf32.3
---------------------------------------
'+' = added ; '-' = removed
+ 2.4.32-orinoco-cve-2005-3180-information-leakage-1 (horms)
Fix for CVE-2005-3180 by Alan Cox, back-ported by Horms. Fixes
and etherleak bug in the orinoco driver. As yet untested.
+ 2.4.32-x86_64-check-for-bad-elf-entry-address-1 (andi kleen)
Fixes a local DOS on Intel systems that lead to an endless recursive
fault. AMD machines don't seem to be affected. Actually based on a
2.6 patch by Suresh Siddha, but the 2.4 implementation is somewhat
different.
+ 2.4.32-information-leak-in-SO_ORIGINAL_DST-and-getname-1 (pavel kankovsky)
It appears sockaddr_in.sin_zero is not zeroed during certain operations
returning IPv4 socket names : getsockopt(...SO_ORIGINAL_DST...),
getsockname() and getpeername().
+ 2.4.32-e1000-do-not-call-msec_delay-in-irq-context-1 (jesse brandeburg)
There are some functions that are called in irq context that need to use
msec_delay_irq instead to avoid a BUG.
+ 2.4.32-fix-overflow-in-inode-1 (Rik van Riel)
The following patch fixes an overflow in inode.c. This overflow can cause
a system to stop reclaiming inodes, with a large amount of memory and
zillions of inodes. This has caused systems to run out of low memory in
real world situations. Thanks go out to Larry Woodman, as well as the
unnamed customer who first tracked this problem down.
+ 2.4.32-make-kernel-work-on-i486-again-1 (jacek lipkowski)
Booting the 2.4.32 kernel compiled for a i486 on an i486 box fails,
because "Kernel compiled for Pentium+, requires TSC feature!" (printed
from check_config() include/asm-i386/bugs.h).
+ 2.4.32-ppc64-fix-sys_rt_sigreturn-return-type-1 (stephen rothwell)
Paul Mackerras noticed that sys_rt_sigreturn's return value was "int".
It needs to be "long" or else the return value of a syscall that is
interrupted by a signal will be truncated to 32 bits and then sign
extended. This causes .e.g mmap's return value to be corrupted if it
is returning an address above 2^31 (which is what caused a SEGV in
malloc). This problem obviously only affects 64 bit processes.
+ 2.4.32-ip_queue-fix-wrong-skb-len-nlmsg_len-assumption-1 (thomas graf)
The size of the skb carrying the netlink message is not equivalent to the
length of the actual netlink message due to padding. ip_queue matches the
length of the payload against the original packet size to determine if
packet mangling is desired, due to the above wrong assumption arbitary
packets may not be mangled depening on their original size.
+ 2.4.32-drm_stub_open-range-checking-1 (marin mitov)
Xorg-6.9.0 SIGSEGFAULTs when the loading of dri module is enabled (direct
rendering). Xorg-6.9.0 (and evidently not the previous versions) has
defined DRM_MAX_MINOR as 255 (and Xorg-6.9.0 tries to open all of them)
while in the kernel: DRM_STUB_MAXCARDS is defined as 16.
+ 2.4.32-sparc-fix-compile-failures-in-math-emu-1 (david miller)
Kill debugging default switch cases in do_one_mathemu(). That case is
handled properly already and gcc hates the empty statement that results
when the debug code is disabled. Pointed out by kaffe.
+ 2.4.32-alpha-fix-recursive-inlining-failure-pci_iommu-1 (solar designer)
Building on alpha with gcc 3.4.5 fails because of recursive inlining.
Simply removing the "inline" from the declaration of sg_fill() makes
it build and work.
+ 2.4.32-build-fix-auto_fs4-changes-broke-ppc64-build-1 (jesse brandeburg)
This patch adds a couple of #include statements verified to fix the
compile for ppc64 and probably will fix the compile on parisc. ppc64
would not build without this fix.
----
^ permalink raw reply
* Re: Idea: Automatic binary driver compiling system
From: Benjamin Bach @ 2006-03-19 16:12 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-kernel
In-Reply-To: <b6c5339f0603190719u6e52ba3cwda15509de3ed947e@mail.gmail.com>
Bob Copeland wrote:
>> Anyways, I'm very happy with the combination of intelligence and
>> idealism on this list, and suddenly I feel more attracted to writing a
>> driver instead. For my Rio Karma mp3 player. It's a USB thing.. should
>> be do-able in 3 months even though I've never written a driver.
>>
>>
>
> I've already done this and it is in 2.6.16. There's still some work
> to be done on the filesystem; check out
> http://linux-karma.sourceforge.net to help out.
>
>
Yeah, I immediately found out =) Some very good explanation on your site
(http://bobcopeland.com/karma/). I see that you've implemented most of
the work, and I can't really figure out any isolated development
suitable for a school project. But please, if you have an idea, say so.
Otherwise I'll probably dig up something. Just needs to be a small
kernel-whatever project.
Is there someone maintaining a list of non-implemented ideas for kernel
features/drivers?
/ Benjamin
^ permalink raw reply
* Re: [PATCH]use kzalloc in vfs where appropriate
From: Arjan van de Ven @ 2006-03-19 16:09 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Matthew Wilcox, viro, linux-fsdevel, linux-kernel
In-Reply-To: <200603191429.21776.oliver@neukum.org>
On Sun, 2006-03-19 at 14:29 +0100, Oliver Neukum wrote:
> Am Samstag, 18. März 2006 11:55 schrieb Arjan van de Ven:
> > On Sat, 2006-03-18 at 11:44 +0100, Oliver Neukum wrote:
> > > Am Freitag, 17. März 2006 22:08 schrieb Matthew Wilcox:
> > > > On Fri, Mar 17, 2006 at 09:58:14PM +0100, Oliver Neukum wrote:
> > > > > --- a/fs/bio.c 2006-03-11 23:12:55.000000000 +0100
> > > > > +++ b/fs/bio.c 2006-03-17 16:44:49.000000000 +0100
> > > > > @@ -635,12 +635,10 @@
> > > > > return ERR_PTR(-ENOMEM);
> > > > >
> > > > > ret = -ENOMEM;
> > > > > - pages = kmalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
> > > > > + pages = kzalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
> > > >
> > > > Didn't we just discuss this one and conclude it needed to use kcalloc
> > > > instead?
> > >
> > > I've found some discussion in the archive, but no conclusion. Could you
> > > elaborate?
> >
> > kcalloc is the array allocator.
> > Here.. you're allocating an array of nr_pages worth of pointers.
> > kcalloc does extra checks because it KNOWS it's an array...
>
> I see. A patch is coming.
> Shouldn't this check from slab.h:
>
> if (n != 0 && size > INT_MAX / n)
> return NULL;
>
> carry an "unlikely"?
gcc is most likely smart enough for that already, and most of the time n
is a compile time constant already :)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox