Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
L
linux
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
linux
Commits
a340bf30
Commit
a340bf30
authored
Sep 09, 2002
by
Andy Grover
Browse files
Options
Browse Files
Download
Plain Diff
Merge groveronline.com:/root/bk/linux-2.5
into groveronline.com:/root/bk/linux-acpi
parents
df9cf6c8
2b5d7502
Changes
6
Hide whitespace changes
Inline
Side-by-side
Showing
6 changed files
with
21 additions
and
19 deletions
+21
-19
Documentation/DocBook/kernel-api.tmpl
Documentation/DocBook/kernel-api.tmpl
+1
-1
Documentation/filesystems/directory-locking
Documentation/filesystems/directory-locking
+8
-8
Documentation/filesystems/porting
Documentation/filesystems/porting
+1
-1
arch/i386/kernel/cpu/intel.c
arch/i386/kernel/cpu/intel.c
+1
-0
init/main.c
init/main.c
+9
-9
kernel/signal.c
kernel/signal.c
+1
-0
No files found.
Documentation/DocBook/kernel-api.tmpl
View file @
a340bf30
...
...
@@ -161,7 +161,7 @@ KAO -->
</sect1>
<sect1><title>
MTRR Handling
</title>
!Earch/i386/kernel/
mtrr
.c
!Earch/i386/kernel/
cpu/mtrr/main
.c
</sect1>
<sect1><title>
PCI Support Library
</title>
!Edrivers/pci/pci.c
...
...
Documentation/filesystems/directory-locking
View file @
a340bf30
...
...
@@ -80,14 +80,14 @@ would have a contended child and we had assumed that no object is its
own descendent. Moreover, there is exactly one cross-directory rename
(see above).
Consider the object blocking the cross-directory rename. One
of
its descendents is locked by cross-directory rename (otherwise we would again
have an infinite set of of contended objects). But that means that means
that cross-directory rename is taking locks out of order. Due to (2) th
e
order hadn't changed since we had acquired filesystem lock. But locking
rules for cross-directory rename guarantee that we do not try to acquire
lock on descendent before the lock on ancestor. Contradiction. I.e
.
deadlock is impossible. Q.E.D.
Consider the object blocking the cross-directory rename. One
of its descendents is locked by cross-directory rename (otherwise we
would again have an infinite set of of contended objects). But that
means that cross-directory rename is taking locks out of order. Du
e
to (2) the order hadn't changed since we had acquired filesystem lock.
But locking rules for cross-directory rename guarantee that we do not
try to acquire lock on descendent before the lock on ancestor
.
Contradiction. I.e.
deadlock is impossible. Q.E.D.
These operations are guaranteed to avoid loop creation. Indeed,
...
...
Documentation/filesystems/porting
View file @
a340bf30
...
...
@@ -69,7 +69,7 @@ Locking change: ->s_vfs_rename_sem is taken only by cross-directory renames.
Most likely there is no need to change anything, but if you relied on
global exclusion between renames for some internal purpose - you need to
change your internal locking. Otherwise exclusion warranties remain the
same (i.e. parents a
re
victim are locked, etc.).
same (i.e. parents a
nd
victim are locked, etc.).
---
[informational]
...
...
arch/i386/kernel/cpu/intel.c
View file @
a340bf30
...
...
@@ -156,6 +156,7 @@ static void __init init_intel(struct cpuinfo_x86 *c)
}
#endif
get_model_name
(
c
);
if
(
c
->
cpuid_level
>
1
)
{
/* supports eax=2 call */
...
...
init/main.c
View file @
a340bf30
...
...
@@ -490,15 +490,6 @@ static void __init do_initcalls(void)
*/
static
void
__init
do_basic_setup
(
void
)
{
#if defined(CONFIG_MTRR)
/* Do this after SMP initialization */
/*
* We should probably create some architecture-dependent "fixup after
* everything is up" style function where this would belong better
* than in init/main.c..
*/
mtrr_init
();
#endif
#ifdef CONFIG_SYSCTL
sysctl_init
();
#endif
...
...
@@ -545,6 +536,15 @@ static int init(void * unused)
*/
child_reaper
=
current
;
#if defined(CONFIG_MTRR)
/* Do this after SMP initialization */
/*
* We should probably create some architecture-dependent "fixup after
* everything is up" style function where this would belong better
* than in init/main.c..
*/
mtrr_init
();
#endif
/* Sets up cpus_possible() */
smp_prepare_cpus
(
max_cpus
);
...
...
kernel/signal.c
View file @
a340bf30
...
...
@@ -1220,6 +1220,7 @@ int get_signal_to_deliver(siginfo_t *info, struct pt_regs *regs)
#endif
EXPORT_SYMBOL
(
recalc_sigpending
);
EXPORT_SYMBOL
(
dequeue_signal
);
EXPORT_SYMBOL
(
flush_signals
);
EXPORT_SYMBOL
(
force_sig
);
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment