Add an rpc credential that is not tied to any particular auth mechanism,
but that can be cached by NFS, and later used to look up a cred for
whichever auth mechanism that turns out to be valid when the RPC call is
being made.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
The current RPCAUTH_LOOKUP_ROOTCREDS flag only works for AUTH_SYS
authentication, and then only as a special case in the code. This patch
removes the auth_sys special casing, and replaces it with generic code.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
This makes 64-bit ptrace calls setting the 64-bit orig_ax field for a
32-bit task sign-extend the low 32 bits up to 64. This matches what a
64-bit debugger expects when tracing a 32-bit task.
This follows on my "x86_64 ia32 syscall restart fix". This didn't
matter until that was fixed.
The debugger ignores or zeros the high half of every register slot it
sets (including the orig_rax pseudo-register) uniformly. It expects
that the setting of the low 32 bits always has the same meaning as a
32-bit debugger setting those same 32 bits with native 32-bit
facilities.
This never arose before because the syscall restart check never
matched any -ERESTART* values due to lack of sign extension. Before
that fix, even 32-bit ptrace setting orig_eax to -1 failed to trigger
the restart check anyway. So this was never noticed as a regression
of 64-bit debuggers vs 32-bit debuggers on the same 64-bit kernel.
Signed-off-by: Roland McGrath <roland@redhat.com>
[ Changed to just do the sign-extension unconditionally on x86-64,
since orig_ax is always just a small integer and doesn't need
the full 64-bit range ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds another Broadcom BCM2045 based device to the blacklist, with
these settings the micro dongle works on my system.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'slab-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm:
slub: fix typo in Documentation/vm/slub.txt
slab: NUMA slab allocator migration bugfix
slub: Do not cross cacheline boundaries for very small objects
slab - use angle brackets for include of kmalloc_sizes.h
slab numa fallback logic: Do not pass unfiltered flags to page allocator
slub statistics: Fix check for DEACTIVATE_REMOTE_FREES
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
ide: update references to Documentation/ide/ide.txt (v2)
ide: move ide.txt to Documentation/ide/
ide: fix buggy code in ide_register_hw()
ide: fix enabling DMA on it821x in "smart" mode
ide-cd: mark REQ_TYPE_ATA_PC write requests with REQ_RW flag
Cleanup some of Documentation directory:
Move Documentation/ide.txt to the ide/ sub-directory.
Fix trailing whitespace while there.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ide_tune_dma() should return '1' if IDE_HFLAG_NO_SET_MODE host flag is set.
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
On Thursday 06 March 2008, walt wrote:
> For me, this commit causes the problem it's intended to fix:
>
> commit 9f10d9ee0a
> Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Tue Feb 26 21:50:35 2008 +0100
>
> ide-cd: fix 'ireason' handling for REQ_TYPE_ATA_PC requests
>
> This fixes some hangs caused by not finishing the transfer before ending
> the request and also makes use of 'ireason == 1' quirk for spurious IRQs.
>
> When I mount a CD there is a long delay, and I see this error message:
>
> hdc: ide_cd_check_ireason: wrong transfer direction!
> cdrom: failed setting lba address space
> hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hdc: drive not ready for command
> <repeated many times>
>
> When I revert this commit everything works properly again, including
> CD burning.
It turned out that REQ_TYPE_ATA_PC write requests were not marked as such
(the previous commit assumed them to be).
Reported-by: walt <w41ter@gmail.com>
Tested-by: walt <w41ter@gmail.com>
Reviewed-by: Borislav Petkov <petkovbb@googlemail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* 'hotfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6:
NFS: Fix dentry revalidation for NFSv4 referrals and mountpoint crossings
NFS: Fix the fsid revalidation in nfs_update_inode()
SUNRPC: Fix a nfs4 over rdma transport oops
NFS: Fix an f_mode/f_flags confusion in fs/nfs/write.c
As long as the directory contents haven't changed, we should just let the
path walk proceed to cross the mountpoint. Apart from being an optimisation
in the case of 'nohide' mountpoint traversals, it also fixes an issue with
referrals: referral inodes don't have valid filehandles, so calling
nfs_revalidate_inode() on them is a bug.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
When we detect that we've crossed a mountpoint on the remote server, we
must take care not to use that inode to revalidate the fsid on our
current superblock. To do so, we label the inode as a remote mountpoint,
and check for that in nfs_update_inode().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Prevent an RPC oops when freeing a dynamically allocated RDMA
buffer, used in certain special-case large metadata operations.
Signed-off-by: Tom Talpey <tmt@netapp.com>
Signed-off-by: James Lentini <jlentini@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
The card state mutex was only initialized when a device was connected,
but used during unload unconditionally, leading to an Oops if a driver
was loaded and unloaded again without ever connecting a device.
Fix this by initializing the mutex as soon as the structure is allocated.
Also add a missing mutex unlock revealed in the same execution path.
This fixes a possible Oops in 2.6.25-rc that was introduced by commit
e468c04894 ("Gigaset: permit module
unload").
Thanks to Roland Kletzing for reporting this problem.
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Tested-by: Roland Kletzing <devzero@web.de>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel:
sched: don't allow rt_runtime_us to be zero for groups having rt tasks
sched: rt-group: fixup schedulability constraints calculation
sched: fix the wrong time slice value for SCHED_FIFO tasks
sched: export task_nice
sched: balance RT task resched only on runqueue
sched: retain vruntime
randconfig testing found a bootup lockup in drivers/char/esp.c because
of a spinlock that wasn't correctly initialized.
I'm not sure why it became more prominent in 2.6.25-rc4, the bug seems
rather old and i've been doing allyesconfig bootups for ages with
CONFIG_ESP enabled.
This fixes this bootup lockup:
PM: Adding info for No Bus:ttyP63
ttyP32 at 0x0240 (irq = 0) is an ESP primary port
BUG: spinlock lockup on CPU#0, swapper/1, f56dd004
Pid: 1, comm: swapper Not tainted 2.6.25-rc4-sched-devel.git-x86-latest.git #402 [<c03ac6f4>] _raw_spin_lock+0x134/0x140
[<c08649be>] _spin_lock_irqsave+0x5e/0x80
[<c0b9fbfe>] ? espserial_init+0x2be/0x6e0
[<c0b9fbfe>] espserial_init+0x2be/0x6e0
[<c0b877a3>] kernel_init+0x83/0x260
[<c0b9f940>] ? espserial_init+0x0/0x6e0
[<c010416a>] ? restore_nocheck_notrace+0x0/0xe
[<c0b87720>] ? kernel_init+0x0/0x260
[<c0b87720>] ? kernel_init+0x0/0x260
[<c0104507>] kernel_thread_helper+0x7/0x10
=======================
kzalloc() is not the way to initialize spinlocks anymore.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch checks if we can set the rt_runtime_us to 0. If there is a
realtime task in the group, we don't want to set the rt_runtime_us as 0
or bad things will happen. (that task wont get any CPU time despite
being TASK_RUNNNG)
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
it was only possible to configure the rt-group scheduling parameters
beyond the default value in a very small range.
that's because div64_64() has a different calling convention than
do_div() :/
fix a few untidies while we are here; sysctl_sched_rt_period may overflow
due to that multiplication, so cast to u64 first. Also that RUNTIME_INF
juggling makes little sense although its an effective NOP.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Trond Myklebust
Roland McGrath
Karsten Keil
Linus Torvalds
Randy Dunlap
Peter Teoh
Bartlomiej Zolnierkiewicz
Tom Talpey
Tilman Schmidt
Ingo Molnar
Dhaval Giani
Peter Zijlstra