We've supported mapping of extents when no block allocation is required
for some time. This patch extends that to mapping of extents when an
allocation has been requested. In that case we try to allocate as many
blocks as are requested, but we might return fewer in case there is
something preventing us from returning the complete amount (e.g. an
already allocated block is in the way).
Currently the only code path which can actually request multiple data
blocks in a single bmap call is the page_mkwrite path and even then it
only happens if there are multiple blocks per page. What this patch does
do however, is merge the allocation requests for metadata (growing the
metadata tree in either height or depth) with the allocation of the data
blocks in the case that both are needed. This results in lower overheads
even in the single block allocation case.
The one thing which we can't handle here at the moment is unstuffing. I
would like to be able to do that, but the problem which arises is that
in order to unstuff one has to get a locked page from the page cache
which results in locking problems in the (usual) case that the caller is
holding the page lock on the page it wishes to map. So that case will
have to be addressed in future patches.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
We've previously been using a "try lock" in readpage on the basis that
it would prevent deadlocks due to the inverted lock ordering (our normal
lock ordering is glock first and then page lock). Unfortunately tests
have shown that this isn't enough. If the glock has a demote request
queued such that run_queue() in the glock code tries to do a demote when
its called under readpage then it will try and write out all the dirty
pages which requires locking them. This then deadlocks with the page
locked by readpage.
The solution is to always require two calls into readpage. The first
unlocks the page, gets the glock and returns AOP_TRUNCATED_PAGE, the
second does the actual readpage and unlocks the glock & page as
required.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[GFS2] Fix bug where we called drop_bh incorrectly
As a result of an earlier patch, drop_bh was being called in cases
when it shouldn't have been. Since we never have a gh in the drop
case and we always have a gh in the promote case, we can use that
extra information to tell which case has been seen.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> Cc: Bob Peterson <rpeterso@redhat.com>
[GFS2] Get inode buffer only once per block map call
In the case that we needed to grow the height of the metadata tree
we were looking up the inode buffer and then brelse()ing it despite
the fact that it is needed later in the block map process.
This patch ensures that we look up the inode's buffer once and only
once during the block map process.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[GFS2] Eliminate (almost) duplicate field from gfs2_inode
The blocks counter is almost a duplicate of the i_blocks
field in the VFS inode. The only difference is that i_blocks
can be only 32bits long for 32bit arch without large single file
support. Since GFS2 doesn't handle the non-large single file
case (for 32 bit anyway) this adds a new config dependency on
64BIT || LSF. This has always been the case, however we've never
explicitly said so before.
Even if we do add support for the non-LSF case, we will still
not require this field to be duplicated since we will not be
able to access oversized files anyway.
So the net result of all this is that we shave 8 bytes from a gfs2_inode
and get our config deps correct.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
This adds a function (currently the only use is during mapping
of already allocated blocks, but watch this space) which iterates
over a number of pointers in a block and returns the extent length.
If the initial pointer is 0 (i.e. unallocated) it will return the
number of unallocated blocks in the extent. If the initial pointer
is allocated, then it returns the number of contiguously allocated
blocks in the extent.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Rather than having to allocate a single block at a time, this patch
allows the block allocator to allocate an extent. Since there is
no difference (so far as the block allocator is concerned) between
data blocks and indirect blocks, it is posible to allocate a single
extent and for the caller to unrevoke just the blocks required
for indirect blocks.
Currently the only bit of GFS2 to make use of this feature is the
build height function. The intention is that gfs2_block_map will
be changed to make use of this feature in future patches.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Thanks to the preceeding patches, the only difference between
these two functions is their name. We can thus merge them
and call the new function gfs2_alloc_block to reflect the
fact that it can allocate either kind of block.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[GFS2] Update gfs2_trans_add_unrevoke to accept extents
By adding an extra argument to gfs2_trans_add_unrevoke we can now
specify an extent length of blocks to unrevoke. This means that
we only need to make one pass through the list for each extent
rather than each block. Currently the only extent length which
is used is 1, but that will change in the future.
Also gfs2_trans_add_unrevoke is removed from gfs2_alloc_meta
since its the only difference between this and gfs2_alloc_data
which is left. This will allow a future patch to merge these
two functions into one (i.e. one call to allocate both data
and metadata in a single extent in the future).
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[GFS2] Merge the rd_last_alloc_meta and rd_last_alloc_data fields
We don't need to keep track of when we last allocated data
and metadata separately since the only thing thats important
when searching for a free block is whether its free or not,
which is independent from what type of block it is.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
There were three fields being used to keep track of the location
of the most recently allocated block for each inode. These have
been merged into a single field in order to better keep the
data and metadata for an inode close on disk, and also to reduce
the space required for storage.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
This patch forms a pair with the previous patch which shrunk
di_height. Like that patch di_depth is renamed i_depth and moved
into struct gfs2_inode directly. Also the field goes from 16 bits
to 8 bits since it is also limited to a max value which is rather
small (17 in this case). In addition we also now validate the field
against this maximum value when its read in.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
The functions in lm.c were just wrappers which were mostly
only used in one other file. By moving the functions to
the files where they are being used, they can be marked
static and also this will usually result in them being inlined
since they are often only used from one point in the code.
A couple of really trivial functions have been inlined by hand
into the function which called them as it makes the code clearer
to do that.
We also gain from one fewer function call in the glock lock and
unlock paths.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[GFS2] Introduce array of buffers to struct metapath
The reason for doing this is to allow all the block mapping code
to share the same array. As a result we can remove two arguments
from lookup_metapath since they are now returned via the array.
We also add a function to drop all refs to buffer heads when we
are done with the metapath. The build_height function shares the
struct metapath, but currently still frees its own buffers, and
this will change in a future patch.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Bob Peterson [Mon, 28 Jan 2008 17:24:35 +0000 (11:24 -0600)]
[GFS2] Misc fixups
This patch contains two small fixups that didn't fit elsewhere.
They are: (1) get rid of temp variable in find_metapath.
(2) Remove vestigial "ret" variable from gfs2_writepage_common.
Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Bob Peterson [Mon, 28 Jan 2008 17:20:10 +0000 (11:20 -0600)]
[GFS2] Only do lo_incore_commit once
This patch is performance related. When we're doing a log flush,
I noticed we were calling buf_lo_incore_commit twice: once for
data bufs and once for metadata bufs. Since this is the same
function and does the same thing in both cases, there should be
no reason to call it twice. Since we only need to call it once,
we can also make it faster by removing it from the generic "lops"
code and making it a stand-along static function.
Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[GFS2] Streamline indirect pointer tree height calculation
This patch improves the calculation of the tree height in order to reduce
the number of operations which are carried out on each call to gfs2_block_map.
In the common case, we now make a single comparison, rather than calculating
the required tree height from scratch each time. Also in the case that the
tree does need some extra height, we start from the current height rather from
zero when we work out what the new height ought to be.
In addition the di_height field is moved into the inode proper and reduced
in size to a u8 since the value must be between 0 and GFS2_MAX_META_HEIGHT (10).
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[GFS2] Speed up gfs2_write_alloc_required, deprecate gfs2_extent_map
This patch removes the call to gfs2_extent_map from gfs2_write_alloc_required,
instead we call gfs2_block_map directly. This results in fewer overall calls
to gfs2_block_map in the multi-block case.
Also, gfs2_extent_map is marked as deprecated so that people know that its
going away as soon as all the callers have been converted.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Mark Lord [Fri, 28 Mar 2008 23:05:25 +0000 (19:05 -0400)]
fix uevent action-string regression
Mark Lord wrote:
>
> On boot, syslog is flooded with "uevent: unsupported action-string;" messages.
..
> Mar 28 14:43:29 shrimp kernel: tty ptyqd: uevent: unsupported
> action-string; this will be ignored in a future kernel version
> Mar 28 14:43:29 shrimp kernel: tty ptyqe: uevent: unsupported
> action-string; this will be ignored in a future kernel version
> Mar 28 14:43:29 shrimp kernel: tty ptyqf: uevent: unsupported
> action-string; this will be ignored in a future kernel version
> Mar 28 14:43:29 shrimp kernel: tty ptyr0: uevent: unsupported
> action-string; this will be ignored in a future kernel version
..
These messages are a regression compared with 2.6.24, which did not
flood the syslog with them.
The actual underlying problem was introduced in 2.6.23, when somebody
made the string parsing no longer accept nul-terminated strings as a
valid input to store_uevent().
Eg. "add\0" was valid prior to 2.6.23, where the code regressed to
require "add" without the '\0'.
This patch fixes the 2.6.23 / 2.6.24 regressions, by having the code
once again tolerate the trailing '\0', if present.
According to GregKH, this mainly affects older Ubuntu systems, such as
the one I have here that requires this fix.
Signed-off-by: Mark Lord <mlord@pobox.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
evdev: Release eventual input device grabs when getting disconnected
When getting disconnected we need to release eventual grabs on the
underlying input device as we also release the input device itself.
Otherwise, we would try to release the grab when the client that
requested it closes its handle, accessing the input device which
might already be freed.
Linus Torvalds [Sun, 30 Mar 2008 21:26:27 +0000 (14:26 -0700)]
Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
libata: ATA_EHI_LPM should be ATA_EH_LPM
pata_sil680: only enable MMIO on Cell blades
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
Harvey Harrison [Fri, 28 Mar 2008 21:23:06 +0000 (14:23 -0700)]
drm: radeon: fix sparse integer as NULL pointer warnings in radeon_mem.c
drivers/char/drm/radeon_mem.c:91:23: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:116:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:124:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:26: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:53: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
Dave Airlie [Sat, 29 Mar 2008 21:51:49 +0000 (07:51 +1000)]
drm/r300: fix bug in r300 userspace hardware wait emission
This interface was originally designed wrong, confusing bit-fields and
integers, major brown paper bag going back many years...
But userspace only ever used 4 values so fix the interface for new
users and fix the implementation to deal with the 4 values userspace
has ever emitted (0x1, 0x2, 0x3, 0x6).
[ conflict in drivers/ide/ide-probe.c fixed manually ]
It turned out that probing order change causes problems for some drives:
http://bugzilla.kernel.org/show_bug.cgi?id=10239
Since root causes are still being investigated and are unlikely to be fixed
before 2.6.25 lets revert this change for now. As a result cable detection
becomes less reliable when compared with 2.6.24 but the affected drives are
useable again.
Reported-by: Richard Genoud <richard.genoud@gmail.com> Bisected-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
There have been reported regressions of the SIL 680 driver when using MMIO, so
this makes it only try MMIO on Cell blades where it's known to be necessary
(the host bridge doesn't do PIO on these).
We'll try to find the root problem with MMIO separately.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Linus Torvalds [Fri, 28 Mar 2008 22:23:01 +0000 (15:23 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
[PATCH] mnt_expire is protected by namespace_sem, no need for vfsmount_lock
[PATCH] do shrink_submounts() for all fs types
[PATCH] sanitize locking in mark_mounts_for_expiry() and shrink_submounts()
[PATCH] count ghost references to vfsmounts
[PATCH] reduce stack footprint in namespace.c
Jesper Juhl [Fri, 28 Mar 2008 21:16:12 +0000 (14:16 -0700)]
driver core: fix small mem leak in driver_add_kobj()
The Coverity checker spotted that we leak the storage allocated to 'name' in
int driver_add_kobj(). The leak looks legit to me - this is the code :
int driver_add_kobj(struct device_driver *drv, struct kobject *kobj,
const char *fmt, ...)
{
va_list args;
char *name;
int ret;
va_start(args, fmt);
name = kvasprintf(GFP_KERNEL, fmt, args);
^^^^^^^^ This dynamically allocates space...
va_end(args);
if (!name)
return -ENOMEM;
return kobject_add(kobj, &drv->p->kobj, "%s", name);
^^^^^^^^ This neglects to free the space allocated
}
Inside kobject_add() a copy of 'name' will be made and used. As far as I can
see, Coverity is correct in flagging this as a leak, but I'd like some
configmation before the patch is applied.
This should fix it.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Andrew Morton [Fri, 28 Mar 2008 21:16:09 +0000 (14:16 -0700)]
memstick: suppress uninitialized-var warning
drivers/memstick/host/tifm_ms.c: In function 'tifm_ms_data_event':
drivers/memstick/host/tifm_ms.c:185: warning: 'p_off' may be used uninitialized in this function
Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Anton Vorontsov [Fri, 28 Mar 2008 21:16:09 +0000 (14:16 -0700)]
mtd: maps/physmap: fix oops in suspend/resume/shutdown ops
# reboot
...
[ 42.351266] Flash device refused suspend due to active operation (state 0)
[ 42.358195] Unable to handle kernel NULL pointer dereference at virtual address 00000078
[ 42.360060] pgd = c7d9c000
[ 42.362769] [00000078] *pgd=a7d8d031, *pte=00000000, *ppte=00000000
[ 42.372902] Internal error: Oops: 17 [#1]
[ 42.376911] Modules linked in:
[ 42.379980] CPU: 0 Not tainted (2.6.25-rc2-10642-ge8f2594-dirty #73)
[ 42.380000] PC is at physmap_flash_shutdown+0x28/0x54
...
[ 42.380000] Backtrace:
[ 42.380000] [<c0130c1c>] (physmap_flash_shutdown+0x0/0x54) from [<c01207c0>] (platform_drv_shutdown+0x20/0x24)
[ 42.380000] r5:28121969 r4:c0229e08
[ 42.380000] [<c01207a0>] (platform_drv_shutdown+0x0/0x24) from [<c011cd40>] (device_shutdown+0x60/0x88)
[ 42.380000] [<c011cce0>] (device_shutdown+0x0/0x88) from [<c003e8a4>] (kernel_restart_prepare+0x2c/0x3c)
[ 42.380000] r4:00000000
[ 42.380000] [<c003e878>] (kernel_restart_prepare+0x0/0x3c) from [<c003ea00>] (kernel_restart+0x14/0x48)
[ 42.380000] [<c003e9ec>] (kernel_restart+0x0/0x48) from [<c003fdc0>] (sys_reboot+0xe8/0x1f8)
[ 42.380000] r4:01234567
[ 42.380000] [<c003fcd8>] (sys_reboot+0x0/0x1f8) from [<c001aa00>] (ret_fast_syscall+0x0/0x2c)
[ 42.380000] r7:00000058 r6:00000004 r5:00000001 r4:00000000
[ 42.380000] Code: 0a000009e7953004e1a00003e1a0e00f (e593f078)
[ 42.650051] ---[ end trace 6d6c26a0fc3141de ]---
Segmentation fault
INIT: no more processes left in this runlevel
While looping for mtd[i]s, we should stop at the mtd[i] == NULL.
This patch also removes unnecessary "if (info)" checks:
suspend/resume/shutdown ops are executed only if probe() is succeeded, so info
is guaranteed to be !NULL.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Cc: David Brownell <david-b@pacbell.net> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If write requests need to be split into pieces, the code must not process them
in parallel because the crypto context cannot be shared. So there can be
parallel crypto operations on one part of the write, but only one write bio
can be processed at a time.
This is not optimal and the workqueue code needs to be optimized for parallel
processing, but for now it solves the problem without affecting the
performance of synchronous crypto operation (most of current dm-crypt users).
opening/reading/mmaping BF54x and BF52x framebuffer simultaneously triggers
BUG: failure at mm/nommu.c:470/add_nommu_vma() Add VM_SHARED to the default
vm_flags
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The HP Compaq nc6120 has the same PCI sub-device ID as the nx6110, and the
SMBus is used by ACPI for thermal management on the nc6120, so Linux should
not attach a native driver to it. This means that this quirk is unsafe and
has to be removed.
I also added a comment to help developers realize that adding new IDs to this
SMBus unhiding quirk table should be done only with great care, and in
particular only after checking that ACPI is not making use of the SMBus.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Tomasz Koprowski <tomek@koprowski.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Neither of the headers actually compiles when included from userpsace nor
should it be made available as userspace tools should be using the libraries
or at least headers from e2fsprogs.
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Harvey Harrison [Fri, 28 Mar 2008 21:16:01 +0000 (14:16 -0700)]
kernel: add bit rotation helpers for 16 and 8 bit
Will replace open-coded variants elsewhere. Done in the same
style as the 32-bit versions.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: John W. Linville <linville@tuxdriver.com> Cc: Joe Perches <joe@perches.com> Cc: Jiri Benc <jbenc@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alessandro Zummo [Fri, 28 Mar 2008 21:15:59 +0000 (14:15 -0700)]
ixp4xx-beeper: add MODULE_ALIAS
The following patch allows ixp4xx-beeper to be loaded by udev
automatically when compiled as a module with kernel versions 2.4.24 and
greater.
This patch is required because 43cc71eed1250755986da4c0f9898f9a635cb3bf
("platform: prefix MODALIAS with "platform:"") changed the modalias
string to have the extra prefix.
LKG7102D7:~# udevinfo -a -p /sys/devices/platform/ixp4xx-beeper.4
looking at device '/devices/platform/ixp4xx-beeper.4':
KERNEL=="ixp4xx-beeper.4"
SUBSYSTEM=="platform"
DRIVER==""
ATTR{modalias}=="platform:ixp4xx-beeper"
udev therefore tries to modprobe platform:ixp4xx-beeper instead of
ixp4xx-beeper.
LKG7102D7:~# udevtest /sys/devices/platform/ixp4xx-beeper.4
...
import_uevent_var: import into environment: 'PHYSDEVBUS=platform'
import_uevent_var: import into environment: 'MODALIAS=platform:ixp4xx-beeper'
main: looking at device '/devices/platform/ixp4xx-beeper.4' from
subsystem 'platform'
wait_for_sysfs: file '/sys/devices/platform/ixp4xx-beeper.4/bus'
appeared after 0 loops
main: run: 'socket:/org/kernel/udev/monitor'
main: run: '/sbin/modprobe --use-blacklist platform:ixp4xx-beeper'
With this patch, depmod adds an alias line (see below) to
modules.alias which allows modprobe to load the right module.
alias platform:ixp4xx-beeper ixp4xx-beeper
Signed-off-by: Gordon Farquharson <gordonfarquharson@gmail.com> Signed-off-by: Alessandro Zummo <a.zummo@towertech.it> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: David Brownell <david-b@pacbell.net> Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Andy Whitcroft [Fri, 28 Mar 2008 21:15:58 +0000 (14:15 -0700)]
update checkpatch.pl to version 0.16
This version brings proper quote tracking across lines, and brings the
handling of comments into the same mechanism ensuring nesting is correctly
handled. It brings the usual flurry of fixes for false positives. It also
brings a number of new checks. The most contentious change will likely be
the checks for NR_CPUS as this throws some new warnings in kernel/sched.c.
Of note:
- all new quote tracking across lines
- all new comment tracking
- new more direct, less ambigious wording for some warnings
- recommends mutexes and completions over semaphores
- recommends strict_strto* over simple_strto*
- report on direct use of NR_CPUS
Andy Whitcroft (22):
Version: 0.16
string quote tracking should cross line boundaries
check spacing round -> correctly across newlines
checks for linux/ against asm/ include files should be warnings
standardise on 'required' and 'prohibited'
take the first end of condition when parsing statements
values: cope with unbalanced brackets
preprocessor #elif is not a function
preprocessor #if should not trigger trailing statement checks
test: allow us to limit output to a single error
recommend real mutexes over semaphores
asm checks should mirror those for __asm__
warn on semaphores being used in place of completions
trailing ; on control structure should ignore do {} while ();
recommend strict_strtoX over simple_strtoX
redo comment handling as a quote type
use of NR_CPUS is normally wrong
consistant spacing should only be about spaces
if brace check suppression should only apply to the top-levels
use tr/// to align spacing for operators
move to using four parameter form of substr
check and report modifications to include/asm
Signed-off-by: Andy Whitcroft <apw@shadowen.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Andrew Morton [Fri, 28 Mar 2008 21:15:57 +0000 (14:15 -0700)]
net/9p/trans_fd.c:p9_trans_fd_init(): module_init functions should return 0 on success
Mar 23 09:06:31 opensuse103 kernel: Installing 9P2000 support
Mar 23 09:06:31 opensuse103 kernel: sys_init_module: '9pnet_fd'->init suspiciously returned 1, it should follow 0/-E convention
Mar 23 09:06:31 opensuse103 kernel: sys_init_module: loading module anyway...
Mar 23 09:06:31 opensuse103 kernel: Pid: 5323, comm: modprobe Not tainted 2.6.25-rc6-git7-default #1
Mar 23 09:06:31 opensuse103 kernel: [<c013c253>] sys_init_module+0x172b/0x17c9
Mar 23 09:06:31 opensuse103 kernel: [<c0108a6a>] sys_mmap2+0x62/0x77
Mar 23 09:06:31 opensuse103 kernel: [<c01059c4>] sysenter_past_esp+0x6d/0xa9
Mar 23 09:06:31 opensuse103 kernel: =======================
Cc: Latchesar Ionkov <lucho@ionkov.net> Cc: Eric Van Hensbergen <ericvh@opteron.(none)> Cc: David S. Miller <davem@davemloft.net> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: <devzero@web.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dave Jones [Fri, 28 Mar 2008 21:15:56 +0000 (14:15 -0700)]
audit: silence two kerneldoc warnings in kernel/audit.c
Silence two kerneldoc warnings.
Warning(kernel/audit.c:1276): No description found for parameter 'string'
Warning(kernel/audit.c:1276): No description found for parameter 'len'
[also fix a typo for bonus points]
Signed-off-by: Dave Jones <davej@codemonkey.org.uk> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sven Schnelle [Fri, 28 Mar 2008 21:15:55 +0000 (14:15 -0700)]
afs: prevent double cell registration
kafs doesn't check if the cell already exists - so if you do an echo "add
newcell.org 1.2.3.4" >/proc/fs/afs/cells it will try to create this cell
again. kobject will also complain about a double registration. To prevent
such problems, return -EEXIST in that case.
Signed-off-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dmitri Monakhov [Fri, 28 Mar 2008 21:15:52 +0000 (14:15 -0700)]
vfs: fix data leak in nobh_write_end()
Current nobh_write_end() implementation ignore partial writes(copied < len)
case if page was fully mapped and simply mark page as Uptodate, which is
totally wrong because area [pos+copied, pos+len) wasn't updated explicitly in
previous write_begin call. It simply contains garbage from pagecache and
result in data leakage.
As you can see file's page contains garbage from pagecache instead of zeros.
#TEST_CASE_END
Attached patch:
- Add sanity check BUG_ON in order to prevent incorrect usage by caller,
This is function invariant because page can has buffers and in no zero
*fadata pointer at the same time.
- Always attach buffers to page is it is partial write case.
- Always switch back to generic_write_end if page has buffers.
This is reasonable because if page already has buffer then generic_write_begin
was called previously.
Signed-off-by: Dmitri Monakhov <dmonakhov@openvz.org> Reviewed-by: Nick Piggin <npiggin@suse.de> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/char/drm/ati_pcigart.c: In function 'drm_ati_pcigart_init':
drivers/char/drm/ati_pcigart.c:125: warning: format '%08X' expects type 'unsigned int', but argument 3 has type 'dma_addr_t'
Cc: Dave Airlie <airlied@linux.ie> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This has been forgotten in commit f5bbdacc419 ("[MTD] NAND Modularize
read function") and nobody compiled the driver.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Joern Engel <joern@wh.fh-wedel.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Andrew Morton [Fri, 28 Mar 2008 18:47:34 +0000 (11:47 -0700)]
Avoid false positive warnings in kmap_atomic_prot() with DEBUG_HIGHMEM
I believe http://bugzilla.kernel.org/show_bug.cgi?id=10318 is a false
positive. There's no way in which networking will be using highmem pages
here, so it won't be taking the KM_USER0 kmap slot, so there's no point in
performing these checks.
Cc: Pawel Staszewski <pstaszewski@artcom.pl> Cc: Ingo Molnar <mingo@elte.hu> Acked-by: Christoph Lameter <clameter@sgi.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ Really sad. We lose almost all real-life coverage of the debug tests
with this patch. Now it will only report problems for the cases where
people actually end up using a HIGHMEM page, not when they just _might_
use one. - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Roland Dreier [Fri, 28 Mar 2008 17:28:17 +0000 (10:28 -0700)]
RDMA/cxgb3: Program hardware IRD with correct value
Because of a typo in iwch_accept_cr(), the cxgb3 connection handling
code programs the hardware IRD (incoming RDMA read queue depth) with
the value that is passed in for the ORD (outgoing RDMA read queue
depth). In particular this means that if an application passes in IRD
> 0 and ORD = 0 (which is a completely sane and valid thing to do for
an app that expects only incoming RDMA read requests), then the
hardware will end up programmed with IRD = 0 and the app will fail in
a mysterious way.
Fix this by using "ep->ird" instead of "ep->ord" in the intended place.
Signed-off-by: Roland Dreier <rolandd@cisco.com> Acked-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / linux-2.6-omap-h63xx.git / log