fix the following 'make includecheck' warning:
Documentation/auxdisplay/cfag12864b-example.c: string.h is included more than once.
Signed-off-by: Jaswinder Singh Rajput <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
In "documentation: update Documentation/filesystem/proc.txt and
Documentation/sysctls" (commit 760df93ec) we merged /proc/sys/fs
documentation in Documentation/sysctl/fs.txt and
Documentation/filesystem/proc.txt, but stale file-nr definition
remained.
This patch adds back the right fs-nr definition for 2.6 kernel.
Signed-off-by: Xiaotian Feng<[email protected]>
Cc: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Documentation/filesystems/sharedsubtree.txt needs updating because the
mount command in util-linux package is well aware of shared subtree
features now. The patch also fixes two typos in sharedsubtree.txt.
Signed-off-by: Peng Tao <[email protected]>
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Miklos Szeredi <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
mount(8) handles shared subtrees just fine, so remove the smount program
from Documentation/filesystems/sharedsubtree.txt.
Fix annoying "Lets" -> "Let's".
Insert space between '#' prompt and "mount" command.
Signed-off-by: Randy Dunlap <[email protected]>
Acked-by: Miklos Szeredi <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
There are many similar code in kernel for one object: convert time between
calendar time and broken-down time.
Here is some source I found:
fs/ncpfs/dir.c
fs/smbfs/proc.c
fs/fat/misc.c
fs/udf/udftime.c
fs/cifs/netmisc.c
net/netfilter/xt_time.c
drivers/scsi/ips.c
drivers/input/misc/hp_sdc_rtc.c
drivers/rtc/rtc-lib.c
arch/ia64/hp/sim/boot/fw-emu.c
arch/m68k/mac/misc.c
arch/powerpc/kernel/time.c
arch/parisc/include/asm/rtc.h
...
We can make a common function for this type of conversion, At least we
can get following benefit:
1: Make kernel simple and unify
2: Easy to fix bug in converting code
3: Reduce clone of code in future
For example, I'm trying to make ftrace display walltime,
this patch will make me easy.
This code is based on code from glibc-2.6
Signed-off-by: Zhao Lei <[email protected]>
Cc: OGAWA Hirofumi <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Andi Kleen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit 6bfde05bf5 ("hugetlbfs: allow the creation of files suitable for
MAP_PRIVATE on the vfs internal mount") altered can_do_hugetlb_shm() to
check if a file is being created for shared memory or mmap(). If this
returns false, we then unconditionally call user_shm_lock() triggering a
warning. This block should never be entered for MAP_HUGETLB. This
patch partially reverts the problem and fixes the check.
Signed-off-by: Eric B Munson <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Adam Litke <[email protected]>
Cc: David Gibson <[email protected]>
Cc: Lee Schermerhorn <[email protected]>
Cc: Nick Piggin <[email protected]>
Cc: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Now that ksm is in mainline it is better to change the default values to
better fit to most of the users.
This patch change the ksm default values to be:
ksm_thread_pages_to_scan = 100 (instead of 200)
ksm_thread_sleep_millisecs = 20 (like before)
ksm_run = KSM_RUN_STOP (instead of KSM_RUN_MERGE - meaning ksm is
disabled by default)
ksm_max_kernel_pages = nr_free_buffer_pages / 4 (instead of 2046)
The important aspect of this patch is: it disables ksm by default, and sets
the number of the kernel_pages that can be allocated to be a reasonable
number.
Signed-off-by: Izik Eidus <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Fix these warnings:
drivers/built-in.o: In function `apanel_remove':
apanel.c:(.text+0x56e852): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `apanel_probe':
apanel.c:(.text+0x56eae3): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `acpi_fujitsu_hotkey_add':
fujitsu-laptop.c:(.text+0x5d7647): undefined reference to `led_classdev_register'
fujitsu-laptop.c:(.text+0x5d76b5): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `wbcir_probe':
winbond-cir.c:(.devinit.text+0x5f375): undefined reference to `led_classdev_register'
winbond-cir.c:(.devinit.text+0x5f663): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `wbcir_remove':
winbond-cir.c:(.devexit.text+0x7f23): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `fujitsu_cleanup':
fujitsu-laptop.c:(.exit.text+0xbe37): undefined reference to `led_classdev_unregister'
fujitsu-laptop.c:(.exit.text+0xbe53): undefined reference to `led_classdev_unregister'
It happens because the new INPUT_WINBOND_CIR driver relies on new-leds
infrastructure - but does not select it in drivers/input/misc/Kconfig.
But it selects LEDS_CLASS, which confuses a number of other drivers into
thinking that all the leds infrastructure is in place.
Fix this by selecting NEW_LEDS as well, like similar drivers do.
Eventually, this whole leds infrastructure complexity should be
cleaned up, it's been going on for years.
Signed-off-by: Ingo Molnar <[email protected]>
Cc: Jesse Barnes <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: David Härdeman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The extent relocation code copy file extents one by one when
relocating data block group. This is inefficient if file
extents are small. This patch makes the relocation code copy
file extents in clusters. So we can can make better use of
read-ahead.
Signed-off-by: Yan Zheng <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
A recent change enforces only one access point to each subvolume. The first
directory entry (the one added when the subvolume/snapshot was created) is
treated as valid access point, all other subvolume links are linked to dummy
empty directories. The dummy directories are temporary inodes that only in
memory, so we can not rename file into them.
Signed-off-by: Yan Zheng <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
For every hardlink in btrfs, there is a corresponding inode back
reference. All inode back references for hardlinks in a given
directory are stored in single b-tree item. The size of b-tree item
is limited by the size of b-tree leaf, so we can only create limited
number of hardlinks to a given file in a directory.
The original code lacks of the check, it oops if the number of
hardlinks goes over the limit. This patch fixes the issue by adding
check to btrfs_link and btrfs_rename.
Signed-off-by: Yan Zheng <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Introduce new truncate helpers truncate_pagecache and inode_newsize_ok.
vmtruncate is also consolidated from mm/memory.c and mm/nommu.c and
into mm/truncate.c.
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Nick Piggin <[email protected]>
Signed-off-by: Al Viro <[email protected]>
sys_mount() reads/copies a whole page for its "type" parameter. When
do_mount_root() passes a kernel address that points to an object which is
smaller than a whole page, copy_mount_options() will happily go past this
memory object, possibly dereferencing "wild" pointers that could be in any
state (hence the kmemcheck warning, which shows that parts of the next
page are not even allocated).
(The likelihood of something going wrong here is pretty low -- first of
all this only applies to kernel calls to sys_mount(), which are mostly
found in the boot code. Secondly, I guess if the page was not mapped,
exact_copy_from_user() _would_ in fact handle it correctly because of its
access_ok(), etc. checks.)
But it is much nicer to avoid the dubious reads altogether, by stopping as
soon as we find a NUL byte. Is there a good reason why we can't do
something like this, using the already existing strndup_from_user()?
[[email protected]: make copy_mount_string() static]
[AV: fix compat mount breakage, which involves undoing akpm's change above]
Reported-by: Ingo Molnar <[email protected]>
Signed-off-by: Vegard Nossum <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Pekka Enberg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: al <[email protected]>
Currently we held s_umount while a filesystem is frozen, despite that we
might return to userspace and unlock it from a different process. Instead
grab an active reference to keep the file system busy and add an explicit
check for frozen filesystems in remount and reject the remount instead
of blocking on s_umount.
Add a new get_active_super helper to super.c for use by freeze_bdev that
grabs an active reference to a superblock from a given block device.
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Now that we have the freeze count there is not much reason for bd_mount_sem
anymore. The actual freeze/thaw operations are serialized using the
bd_fsfreeze_mutex, and the only other place we take bd_mount_sem is
get_sb_bdev which tries to prevent mounting a filesystem while the block
device is frozen. Instead of add a check for bd_fsfreeze_count and
return -EBUSY if a filesystem is frozen. While that is a change in user
visible behaviour a failing mount is much better for this case rather
than having the mount process stuck uninterruptible for a long time.
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Al Viro <[email protected]>
the two places inside exofs that where taking the BKL were:
exofs_put_super() - .put_super
and
exofs_sync_fs() - which is .sync_fs and is also called from
.write_super.
Now exofs_sync_fs() is protected from itself by also taking
the sb_lock.
exofs_put_super() directly calls exofs_sync_fs() so there is no
danger between these two either.
In anyway there is absolutely nothing dangerous been done
inside exofs_sync_fs().
Unless there is some subtle race with the actual lifetime of
the super_block in regard to .put_super and some other parts
of the VFS. Which is highly unlikely.
Signed-off-by: Boaz Harrosh <[email protected]>
Signed-off-by: Al Viro <[email protected]>
romfs_fill_super() assumes that romfs_iget() returns NULL when
it fails. romfs_iget() actually returns ERR_PTR(-ve) in that
case...
Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Add two helpers that allow access to the seq_file's own buffer, but
hide the internal details of seq_files.
This allows easier implementation of special purpose filling
functions. It also cleans up some existing functions which duplicated
the seq_file logic.
Make these inline functions in seq_file.h, as suggested by Al.
Signed-off-by: Miklos Szeredi <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Signed-off-by: Al Viro <[email protected]>
sb->s_maxbytes is supposed to indicate the maximum size of a file that can
exist on the filesystem. It's declared as an unsigned long long.
Even if a filesystem has no inherent limit that prevents it from using
every bit in that unsigned long long, it's still problematic to set it to
anything larger than MAX_LFS_FILESIZE. There are places in the kernel
that cast s_maxbytes to a signed value. If it's set too large then this
cast makes it a negative number and generally breaks the comparison.
Change s_maxbytes to be loff_t instead. That should help eliminate the
temptation to set it too large by making it a signed value.
Also, add a warning for couple of releases to help catch filesystems that
set s_maxbytes too large. Eventually we can either convert this to a
BUG() or just remove it and in the hope that no one will get it wrong now
that it's a signed value.
Signed-off-by: Jeff Layton <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Robert Love <[email protected]>
Cc: Mandeep Singh Baines <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
If fiemap_check_ranges is passed a large enough value, then it's
possible that the value would be cast to a signed value for comparison
against s_maxbytes when we change it to loff_t. Make sure that doesn't
happen by explicitly casting s_maxbytes to an unsigned value for the
purposes of comparison.
Signed-off-by: Jeff Layton <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Robert Love <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Mandeep Singh Baines <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
seq_path_root() is returning a return value of successful __d_path()
instead of returning a negative value when mangle_path() failed.
This is not a bug so far because nobody is using return value of
seq_path_root().
Signed-off-by: Tetsuo Handa <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Do a similar optimization as earlier for touch_atime. Getting the lock in
mnt_get_write is relatively costly, so try all avenues to avoid it first.
This patch is careful to still only update inode fields inside the lock
region.
This didn't show up in benchmarks, but it's easy enough to do.
[[email protected]: fix typo in comment]
[[email protected]: fix inverted test of mnt_want_write_file()]
Signed-off-by: Andi Kleen <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Valerie Aurora <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Dave Hansen <[email protected]>
Signed-off-by: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Some benchmark testing shows touch_atime to be high up in profile logs for
IO intensive workloads. Most likely that's due to the lock in
mnt_want_write(). Unfortunately touch_atime first takes the lock, and
then does all the other tests that could avoid atime updates (like noatime
or relatime).
Do it the other way round -- first try to avoid the update and only then
if that didn't succeed take the lock. That works because none of the
atime avoidance tests rely on locking.
This also eliminates a goto.
Signed-off-by: Andi Kleen <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Reviewed-by: Valerie Aurora <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Dave Hansen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Hugetlbfs needs to do special things instead of truncate_inode_pages().
Currently, it copied generic_forget_inode() except for
truncate_inode_pages() call which is asking for trouble (the code there
isn't trivial). So create a separate function generic_detach_inode()
which does all the list magic done in generic_forget_inode() and call
it from hugetlbfs_forget_inode().
Signed-off-by: Jan Kara <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Impact: have simple_read_from_buffer conform to standards
It was brought to my attention by Andrew Morton, Theodore Tso, and H.
Peter Anvin that a read from userspace should only return -EFAULT if
nothing was actually read.
Looking at the simple_read_from_buffer I noticed that this function does
not conform to that rule. This patch fixes that function.
[[email protected]: simplification suggested by hpa]
[[email protected]: fix count==0 handling]
Signed-off-by: Steven Rostedt <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Cc: Ingo Molnar <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Instead of remembering to specify DTB= on the make commandline, this commit
allows the much friendlier make simpleImage.<dts>
where <dts>.dts is expected to be found in arch/microblaze/boot/dts/
The resulting vmlinux, with the compiled DTS linked in, will be copied to
boot/simpleImage.<dts>
This mirrors the same functionality as on PowerPC,
albeit achieving it in a slightly different way.
+ strip simpleImage file
The size of output file is very similar to linux.bin.
vmlinux - full elf without fdt blob
simpleImage.<dtb name>.unstrip - full elf with fdt blob
simpleImage.<dtb name> - stripped elf with fdt blob
Add symlink to generic system.dts in platform folder
Signed-off-by: John Williams <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Git commit 79741dd changes idle cputime accounting, but unfortunately
the /proc/uptime file hasn't caught up. Here the idle time calculation
from /proc/stat is copied over.
Signed-off-by: Michael Abbott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Currently the audit subsystem prints uncompressed IPv6 addresses which not
only differs from common usage but also results in ridiculously large audit
strings which is not a good thing. This patch fixes this by simply converting
audit to always print compressed IPv6 addresses.
Old message example:
audit(1253576792.161:30): avc: denied { ingress } for
saddr=0000:0000:0000:0000:0000:0000:0000:0001 src=5000
daddr=0000:0000:0000:0000:0000:0000:0000:0001 dest=35502 netif=lo
scontext=system_u:object_r:unlabeled_t:s15:c0.c1023
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
New message example:
audit(1253576792.161:30): avc: denied { ingress } for
saddr=::1 src=5000 daddr=::1 dest=35502 netif=lo
scontext=system_u:object_r:unlabeled_t:s15:c0.c1023
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Eric Paris <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Audit will not respond to signal requests if selinux is disabled since it is
unable to translate the 0 sid from the sending process to a context. This
patch just doesn't send the context info if there isn't any.
Signed-off-by: Eric Paris <[email protected]>
Signed-off-by: Al Viro <[email protected]>
pahole pointed out that on x86_64 struct audit_context can be rearrainged
to save 16 bytes per struct. Since we have an audit_context per task this
can acually be a pretty significant gain.
Signed-off-by: Eric Paris <[email protected]>
Signed-off-by: Al Viro <[email protected]>
pahole showed that struct audit_watch had two holes:
struct audit_watch {
atomic_t count; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
char * path; /* 8 8 */
dev_t dev; /* 16 4 */
/* XXX 4 bytes hole, try to pack */
long unsigned int ino; /* 24 8 */
struct audit_parent * parent; /* 32 8 */
struct list_head wlist; /* 40 16 */
struct list_head rules; /* 56 16 */
/* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
/* size: 72, cachelines: 2, members: 7 */
/* sum members: 64, holes: 2, sum holes: 8 */
/* last cacheline: 8 bytes */
}; /* definitions: 1 */
by moving dev after count we save 8 bytes, actually improving cacheline
usage. There are typically very few of these in the kernel so it won't be
a large savings, but it's a good thing no matter what.
Signed-off-by: Eric Paris <[email protected]>
Signed-off-by: Al Viro <[email protected]>
* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus: (39 commits)
cpumask: Move deprecated functions to end of header.
cpumask: remove unused deprecated functions, avoid accusations of insanity
cpumask: use new-style cpumask ops in mm/quicklist.
cpumask: use mm_cpumask() wrapper: x86
cpumask: use mm_cpumask() wrapper: um
cpumask: use mm_cpumask() wrapper: mips
cpumask: use mm_cpumask() wrapper: mn10300
cpumask: use mm_cpumask() wrapper: m32r
cpumask: use mm_cpumask() wrapper: arm
cpumask: Use accessors for cpu_*_mask: um
cpumask: Use accessors for cpu_*_mask: powerpc
cpumask: Use accessors for cpu_*_mask: mips
cpumask: Use accessors for cpu_*_mask: m32r
cpumask: remove arch_send_call_function_ipi
cpumask: arch_send_call_function_ipi_mask: s390
cpumask: arch_send_call_function_ipi_mask: powerpc
cpumask: arch_send_call_function_ipi_mask: mips
cpumask: arch_send_call_function_ipi_mask: m32r
cpumask: arch_send_call_function_ipi_mask: alpha
cpumask: remove obsolete topology_core_siblings and topology_thread_siblings: ia64
...
* remove asm/atomic.h inclusion from linux/utsname.h --
not needed after kref conversion
* remove linux/utsname.h inclusion from files which do not need it
NOTE: it looks like fs/binfmt_elf.c do not need utsname.h, however
due to some personality stuff it _is_ needed -- cowardly leave ELF-related
headers and files alone.
Signed-off-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
This reverts commit c02e3f361c ("kmod: fix race in usermodehelper code")
The patch is wrong. UMH_WAIT_EXEC is called with VFORK what ensures
that the child finishes prior returing back to the parent. No race.
In fact, the patch makes it even worse because it does the thing it
claims not do:
- It calls ->complete() on UMH_WAIT_EXEC
- the complete() callback may de-allocated subinfo as seen in the
following call chain:
[<c009f904>] (__link_path_walk+0x20/0xeb4) from [<c00a094c>] (path_walk+0x48/0x94)
[<c00a094c>] (path_walk+0x48/0x94) from [<c00a0a34>] (do_path_lookup+0x24/0x4c)
[<c00a0a34>] (do_path_lookup+0x24/0x4c) from [<c00a158c>] (do_filp_open+0xa4/0x83c)
[<c00a158c>] (do_filp_open+0xa4/0x83c) from [<c009ba90>] (open_exec+0x24/0xe0)
[<c009ba90>] (open_exec+0x24/0xe0) from [<c009bfa8>] (do_execve+0x7c/0x2e4)
[<c009bfa8>] (do_execve+0x7c/0x2e4) from [<c0026a80>] (kernel_execve+0x34/0x80)
[<c0026a80>] (kernel_execve+0x34/0x80) from [<c004b514>] (____call_usermodehelper+0x130/0x148)
[<c004b514>] (____call_usermodehelper+0x130/0x148) from [<c0024858>] (kernel_thread_exit+0x0/0x8)
and the path pointer was NULL. Good that ARM's kernel_execve()
doesn't check the pointer for NULL or else I wouldn't notice it.
The only race there might be is with UMH_NO_WAIT but it is too late for
me to investigate it now. UMH_WAIT_PROC could probably also use VFORK
and we could save one exec. So the only race I see is with UMH_NO_WAIT
and recent scheduler changes where the child does not always run first
might have trigger here something but as I said, it is late....
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Acked-by: Neil Horman <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
During releasepage, we try to drop any extent_state structs for the
bye offsets of the page we're releaseing. But the code was incorrectly
telling clear_extent_bit to delete the state struct unconditionallly.
Normally this would be fine because we have the page locked, but other
parts of btrfs will lock down an entire extent, the most common place
being IO completion.
releasepage was deleting the extent state without first locking the extent,
which may result in removing a state struct that another process had
locked down. The fix here is to leave the NODATASUM and EXTENT_LOCKED
bits alone in releasepage.
Signed-off-by: Chris Mason <[email protected]>
If test_range_bit finds an extent that goes all the way to (u64)-1, it
can incorrectly wrap the u64 instead of treaing it like the end of
the address space.
This just adds a check for the highest possible offset so we don't wrap.
Signed-off-by: Chris Mason <[email protected]>
Both set and clear_extent_bit allow passing a cached
state struct to reduce rbtree search times. clear_extent_bit
was improperly bypassing some of the checks around making sure
the extent state fields were correct for a given operation.
The fix used here (from Yan Zheng) is to use the hit_next
goto target instead of jumping all the way down to start clearing
bits without making sure the cached state was exactly correct
for the operation we were doing.
This also fixes up the setting of the start variable for both
ops in the case where we find an overlapping extent that
begins before the range we want to change. In both cases
we were incorrectly going backwards from the original
requested change.
Signed-off-by: Chris Mason <[email protected]>
Saves us one cycle of alloc-add-free if the queue was full.
Signed-off-by: Amit Shah <[email protected]>
Signed-off-by: Rusty Russell <[email protected]> (modified)
Now we can tell the theoretical capacity remaining in the output
queue, virtio_net can waste entries by stopping the queue early.
It doesn't work in the case of indirect buffers and kmalloc failure,
but that's rare (we could drop the packet in that case, but other
drivers return TX_BUSY for similar reasons).
For the record, I think this patch reflects poorly on the linux
network API.
Signed-off-by: Rusty Russell <[email protected]>
Cc: Dinesh Subhraveti <[email protected]>
We put the virtio_net_hdr into the skb's cb region; turn this into a
union to clean up the code slightly and allow future expansion.
Signed-off-by: Rusty Russell <[email protected]>
Cc: Mark McLoughlin <[email protected]>
Cc: Dinesh Subhraveti <[email protected]>
The virtio_net driver is complicated by the two methods of freeing old
xmit buffers (in addition to freeing old ones at the start of the xmit
path).
The original code used a 1/10 second timer attached to xmit_free(),
reset on every xmit. Before we orphaned skbs on xmit, the
transmitting userspace could block with a full socket until the timer
fired, the skb destructor was called, and they were re-woken.
So we added the VIRTIO_F_NOTIFY_ON_EMPTY feature: supporting devices
send an interrupt (even if normally suppressed) on an empty xmit ring
which makes us schedule xmit_tasklet(). This was a benchmark win.
Unfortunately, VIRTIO_F_NOTIFY_ON_EMPTY makes quite a lot of work: a
host which is faster than the guest will fire the interrupt every xmit
packet (slowing the guest down further). Attempting mitigation in the
host adds overhead of userspace timers (possibly with the additional
pain of signals), and risks increasing latency anyway if you get it
wrong.
In practice, this effect was masked by benchmarks which take advantage
of GSO (with its inherent transmit batching), but it's still there.
Now we orphan xmitted skbs, the pressure is off: remove both paths and
no longer request VIRTIO_F_NOTIFY_ON_EMPTY. Note that the current
QEMU will notify us even if we don't negotiate this feature (legal,
but suboptimal); a patch is outstanding to improve that.
Move the skb_orphan/nf_reset to after we've done the send and notified
the other end, for a slight optimization.
Signed-off-by: Rusty Russell <[email protected]>
Cc: Mark McLoughlin <[email protected]>
Josh Triplett