lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 4 Sep 2006 16:36:44 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Steven Whitehouse <swhiteho@...hat.com>
cc:	linux-kernel@...r.kernel.org,
	Russell Cattelan <cattelan@...hat.com>,
	David Teigland <teigland@...hat.com>,
	Ingo Molnar <mingo@...e.hu>, hch@...radead.org
Subject: Re: [PATCH 04/16] GFS2: Daemons and address space operations


>> >+	offset += (2*sizeof(__be64) - 1);
>> 
>> >+#ifndef __LOPS_DOT_H__
>> >+#define __LOPS_DOT_H__
>> 
>> +struct gfs2_log_operations;
>> 
>> Making sure every .h file would "compile" on its own, this also means #include
>> <linux/list.h> for the below, f.ex..
>> 
>Is this really a requirement? I suspect there are a fair few exception
>to this over the kernel code.

A requirement - not yet. I could not find my own post about it, but this 
one is a similar one two years earlier http://lkml.org/lkml/2004/6/15/90

>> Maybe there should be at least one humna person listen in AUTHOR.
>> 
>Ok, I'll get back to you on that one :-)

Should have been "human" of course.

>Are you saying that they should all end in a , or that they should not,
>or even just that it should be consistent?

There seems to be no explicit CodingStyle rule at this point, so you are 
free to choose either. Just be consistent (like with the goto labels).

>> >+++ b/fs/gfs2/ops_address.c
>> >+	if (likely(file != &gfs2_internal_file_sentinal)) {
>> 
>> The thing is usually called "sentinel". Alan might prove me wrong that both
>> spelling variants are possible :-)
>> 
>I think you are right, so I've changed it.

http://dictionary.reference.com/search?q=sentinal&x=0&y=0
W.W.W.W.W.

>> >+static void stuck_releasepage(struct buffer_head *bh)
>> >+{
>> >+static unsigned limit = 0;
>> 
>> Is this really ok to have?
>> 
>I think so. I don't really care about the odd race here. All I want to
>do is ensure that in the (very unlikely, I hope) situation of this
>function being called, we don't land up generating huge amounts of
>debugging information. Usually only the first message will have the

There is printk_ratelimit() and SUBSYSTEM_ratelimit().

>useful information in it, so this was just to ensure that we are not
>flooded. I have made a slight change to it though. Let me know if you'd
>like some further changes in this area.


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ