* [refpolicy] kernel_devices.patch
From: Christopher J. PeBenito @ 2009-03-05 15:59 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <49AEF360.2060204@redhat.com>
On Wed, 2009-03-04 at 16:32 -0500, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F11/kernel_devices.patch
>
>
> labels for
>
> /dev/3dfx
> /dev/autofs
> /dev/gfx
> /dev/graphics
> ...
>
>
> Java wants to attempt to append to the rand device. Dontaudit for now
>
> interface to manage device_t directories
>
> interfaces to handle new null devices
> usb devices
>
> kvm
Merged with a bunch of reorganization.
Is this right?
+/dev/bometric/sensor.* -c gen_context(system_u:object_r:event_device_t,s0)
should it be /dev/biometric instead of /dev/bometric?
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
^ permalink raw reply
* Re: [PATCH 2/4] soc-dai: add bitfields for hardware I2S formats
From: pHilipp Zabel @ 2009-03-05 15:58 UTC (permalink / raw)
To: Daniel Mack; +Cc: alsa-devel, Tim Ruetz, Mark Brown, Liam Girdwood
In-Reply-To: <20090305125521.GB29699@buzzloop.caiaq.de>
On Thu, Mar 5, 2009 at 1:55 PM, Daniel Mack <daniel@caiaq.de> wrote:
> On Thu, Mar 05, 2009 at 12:03:35PM +0000, Mark Brown wrote:
>> > > The other option would be to use the TDM mode interface to set this up
>> > > since that's roughly what it is; my main concern here is that we already
>> > > have two ways of doing this and I'd like to try to keep the number down
>> > > for consistency.
>>
>> > Probably a matter of taste, but IMO TDM mode is not the place either.
>> > Userspace could decide sending out 24bit samples out of a sudden (which
>> > the CPU DAI might accept) and in this case, you'd need some special
>> > logic in the board file again to set up deviders, time slots etc, right?
>>
>> That's why the clocking interface is generally used here - it's more
>> orthogonal.
>
> Hmm, how would you express 24 sample bits with 32 clocks per channel? I
> might not have gotten your point yet - could you provide an example?
I'm still a bit confused by the alsa formats and how they interact
with the SSP formats.
Do I understand correctly that S24_3LE (24-bit packed in 3 bytes)
can't be supported due to limitations in (at least PXA27x's) DMA
engine?
So the remaining 24-bit formats are S24_LE and S32_LE anyway, both of
which are 24-bit packed in 32 bits (either LSB or MSB aligned).
regards
Philipp
^ permalink raw reply
* Re: [linux-lvm] LVM partition type
From: Bryn M. Reeves @ 2009-03-05 15:59 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <ffa0f8300903050753q6dc7c47bx6302d31d174a3dec@mail.gmail.com>
Tejas Sumant wrote:
> Hi there,
>
> I created a physical volume using pvcreate command on /dev/sda. When I
> checked the partition entries in MBR for /dev/sda using fdisk observed
> that no partitions were displayed.
The pvcreate command only creates LVM2 labels, it does not update the
MBR or other disk label at all.
> Why pvcreate doesnt make partition entry with type 8e in MBR? Which
That's your job ;)
If you chose to use partitions for PVs then you need to create those
partitions and set their type codes appropriately (although LVM2
doesn't actually check/use those type codes anywhere - it's really
more of a "documentation" step these days).
> partition entry gets used in case whole disk is made PV?
None of them. If you use the whole disk as a PV it should not have any
MBR at all.
Regards,
Bryn.
^ permalink raw reply
* Re: Re: Continuing problems booting
From: Pasi Kärkkäinen @ 2009-03-05 15:57 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Jeremy Fitzhardinge, xen-devel, M A Young
In-Reply-To: <49AF80C1.2060307@redhat.com>
On Thu, Mar 05, 2009 at 08:35:29AM +0100, Gerd Hoffmann wrote:
> Jeremy Fitzhardinge wrote:
> > Gerd Hoffmann wrote:
> >> Jeremy Fitzhardinge wrote:
> >>
> >>> Yes, I think the legacy interrupts are not being set up completely, but
> >>> I'm not quite sure how they should be set up. Will look into it.
> >>>
> >>
> >> FYI: Recently my dated, apic-less i386 laptop started to successfully
> >> boot the pv_ops/dom0 kernel, all the way up to userspace.
> >>
> >
> > Do you get a vga console? Can you start domains?
>
> gfx console works (i.e. kernel /xen-3.3.gz vga=gfx-1024x768x16).
> vga text console didn't last time I tried.
>
VGA text console doesn't work for me either.
I've only managed to get the serial console working.. although I haven't
tried any graphics modes yet.
Maybe I should play with these again..
-- Pasi
^ permalink raw reply
* [refpolicy] admin_tmpreaper.patch
From: Daniel J Walsh @ 2009-03-05 15:57 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_tmpreaper.patch
tmpreaper lists inotify
Needs to getattr all over the place, Random files can be placed in /tmp
via mv so needs to getattr. user_home_t files often end up in /tmp and
should be deleted.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv9nYACgkQrlYvE4MpobNRGQCfSkaHK9vhne9t2FzY19kwJUSy
XT4An3ry13o59wrq0YlQab+tQYyfxBoj
=K5rr
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 7/7] PPC64: Don't fault at lwsync
From: Alexander Graf @ 2009-03-05 15:57 UTC (permalink / raw)
To: Paul Brook; +Cc: blauwirbel, Alexander Graf, qemu-devel
In-Reply-To: <200903051507.30592.paul@codesourcery.com>
Paul Brook wrote:
> On Thursday 05 March 2009, Alexander Graf wrote:
>
>> Right now we can throw a fault on lwsync, even though the fault is
>> actually caused by the instruction after lwsync.
>>
>> I haven't found the magic that messed this up, but for now we can
>> just end the TB on lwsync, forcing the next command to issue faults
>> itself.
>>
>> If anyone knows how to really fix this, please step forward and do
>> so. This only makes things work at all for me :-).
>>
>
> Where is the subsequent fault coming from? I suspect the real bug is nothing
> to do with lwsync, and the subsequent fault is actually just corrupting the
> CPU state. As discussed recently this is the same bug SPARC has with its
> unassigned access handlers.
>
> Paul
>
Without the patch I get:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0000000000ba524
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA PowerMac
Modules linked in:
Supported: Yes
NIP: c0000000000ba524 LR: c000000000775a0c CTR: c0000000007759e8
REGS: c0000000061afb10 TRAP: 0300 Not tainted (2.6.27.7-9-ppc64)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 84000044 XER: 20000000
DAR: 0000000000000000, DSISR: 0000000040000000
TASK = c00000000619d560[1] 'swapper' THREAD: c0000000061ac000 CPU: 0
GPR00: ffffffffffffffff c0000000061afd90 c0000000009bbce8 0000000000000000
GPR04: 0000000000000000 0000000000000000 0000000000000000 c000000000a82c80
GPR08: 0000000000000613 c00000000619d560 c0000000070704c0 c0000000061ac000
GPR12: 0000000088000044 c000000000a82c80 0000000000051b63 0000000000051a41
GPR16: 0000000000051b5b 000000000004003c 0000000000053958 000000000005345e
GPR20: 0000000000052fd4 0000000000063dc8 0000000000063db4 00000000fff0245c
GPR24: 4000000002110000 c0000000007932f8 c000000000b077a8 0000000000000000
GPR28: c0000000009621f0 c0000000007b01c8 c000000000938f18 c0000000007afce0
NIP [c0000000000ba524] .cmpxchg_futex_value_locked+0x38/0x78
LR [c000000000775a0c] .futex_init+0x24/0xac
Call Trace:
[c0000000061afd90] [c0000000007759c0] .init_tstats_procfs+0x2c/0x54
(unreliable)
[c0000000061afe10] [c00000000000944c] .do_one_initcall+0x78/0x194
[c0000000061aff00] [c000000000750440] .kernel_init+0xd0/0x148
[c0000000061aff90] [c00000000002ad84] .kernel_thread+0x4c/0x68
Instruction dump:
39290001 912b0014 7c8407b4 7ca507b4 e92d01b0 e8090520 7fa30040 419d0038
e92d01b0 e8090520 2ba00003 409d0028 <7c2004ac> 7c001828 7c002000 40c20010
---[ end trace 561bb236c800851f ]---
note: swapper[1] exited with preempt_count 1
swapper used greatest stack depth: 9296 bytes left
Kernel panic - not syncing: Attempted to kill init!
Which is this translation block:
NIP c0000000000ba524 LR c000000000775a0c CTR c0000000007759e8 XER 20000000
MSR 8000000000009032 HID0 0000000060000000 HF 8000000000000000 idx 1
TB 00000000 d8b159bb DECR 0007c417
GPR00 ffffffffffffffff c0000000061afd90 c0000000009bbce8 0000000000000000
GPR04 0000000000000000 0000000000000000 0000000000000000 c000000000a82c80
GPR08 0000000000000613 c00000000619d560 c0000000070704c0 c0000000061ac000
GPR12 0000000088000044 c000000000a82c80 0000000000051b63 0000000000051a41
GPR16 0000000000051b5b 000000000004003c 0000000000053958 000000000005345e
GPR20 0000000000052fd4 0000000000063dc8 0000000000063db4 00000000fff0245c
GPR24 4000000002110000 c0000000007932f8 c000000000b077a8 0000000000000000
GPR28 c0000000009621f0 c0000000007b01c8 c000000000938f18 c0000000007afce0
CR 84000044 [ L G - - - - G G ] RES ffffffffffffffff
FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR 00000000
SRR0 c000000000774950 SRR1 8000000000009032 SDR1 0000000007c00003
IN:
0xc0000000000ba524: lwsync
0xc0000000000ba528: lwarx r0,0,r3
0xc0000000000ba52c: cmpw r0,r4
0xc0000000000ba530: bne- 0xc0000000000ba540
And I seriously have trouble understanding how a data storage exception
could happen on the lwsync opcode. It looks like R3 became 0 from the
guest's point of view after lwsync though - hum.
Alex
^ permalink raw reply
* [PATCH] ath9k: create a common debugfs_root for all device instances
From: Gabor Juhos @ 2009-03-05 15:55 UTC (permalink / raw)
To: John W. Linville
Cc: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org,
Gabor Juhos, Imre Kaloz
The driver are trying to create an 'ath9k' directory in debugfs for each
device currently. If there are more than one device in the system, the
second try will always fail.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
---
drivers/net/wireless/ath9k/debug.c | 24 ++++++++++++++++++------
drivers/net/wireless/ath9k/debug.h | 12 +++++++++++-
drivers/net/wireless/ath9k/main.c | 13 ++++++++++++-
3 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath9k/debug.c b/drivers/net/wireless/ath9k/debug.c
index 0c422c5..3b645ee 100644
--- a/drivers/net/wireless/ath9k/debug.c
+++ b/drivers/net/wireless/ath9k/debug.c
@@ -19,6 +19,8 @@
static unsigned int ath9k_debug = DBG_DEFAULT;
module_param_named(debug, ath9k_debug, uint, 0);
+static struct dentry *ath9k_debugfs_root;
+
void DPRINTF(struct ath_softc *sc, int dbg_mask, const char *fmt, ...)
{
if (!sc)
@@ -334,12 +336,8 @@ int ath9k_init_debug(struct ath_softc *sc)
{
sc->debug.debug_mask = ath9k_debug;
- sc->debug.debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
- if (!sc->debug.debugfs_root)
- goto err;
-
sc->debug.debugfs_phy = debugfs_create_dir(wiphy_name(sc->hw->wiphy),
- sc->debug.debugfs_root);
+ ath9k_debugfs_root);
if (!sc->debug.debugfs_phy)
goto err;
@@ -374,5 +372,19 @@ void ath9k_exit_debug(struct ath_softc *sc)
debugfs_remove(sc->debug.debugfs_interrupt);
debugfs_remove(sc->debug.debugfs_dma);
debugfs_remove(sc->debug.debugfs_phy);
- debugfs_remove(sc->debug.debugfs_root);
+}
+
+int ath9k_debug_create_root(void)
+{
+ ath9k_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
+ if (!ath9k_debugfs_root)
+ return -ENOENT;
+
+ return 0;
+}
+
+void ath9k_debug_remove_root(void)
+{
+ debugfs_remove(ath9k_debugfs_root);
+ ath9k_debugfs_root = NULL;
}
diff --git a/drivers/net/wireless/ath9k/debug.h b/drivers/net/wireless/ath9k/debug.h
index 01681f2..89ba818 100644
--- a/drivers/net/wireless/ath9k/debug.h
+++ b/drivers/net/wireless/ath9k/debug.h
@@ -102,7 +102,6 @@ struct ath_stats {
struct ath9k_debug {
int debug_mask;
- struct dentry *debugfs_root;
struct dentry *debugfs_phy;
struct dentry *debugfs_dma;
struct dentry *debugfs_interrupt;
@@ -113,6 +112,8 @@ struct ath9k_debug {
void DPRINTF(struct ath_softc *sc, int dbg_mask, const char *fmt, ...);
int ath9k_init_debug(struct ath_softc *sc);
void ath9k_exit_debug(struct ath_softc *sc);
+int ath9k_debug_create_root(void);
+void ath9k_debug_remove_root(void);
void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status);
void ath_debug_stat_rc(struct ath_softc *sc, struct sk_buff *skb);
void ath_debug_stat_retries(struct ath_softc *sc, int rix,
@@ -134,6 +135,15 @@ static inline void ath9k_exit_debug(struct ath_softc *sc)
{
}
+static inline int ath9k_debug_create_root(void)
+{
+ return 0;
+}
+
+static inline void ath9k_debug_remove_root(void)
+{
+}
+
static inline void ath_debug_stat_interrupt(struct ath_softc *sc,
enum ath9k_int status)
{
diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k/main.c
index 28200ce..d37924a 100644
--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -2712,12 +2712,20 @@ static int __init ath9k_init(void)
goto err_out;
}
+ error = ath9k_debug_create_root();
+ if (error) {
+ printk(KERN_ERR
+ "ath9k: Unable to create debugfs root: %d\n",
+ error);
+ goto err_rate_unregister;
+ }
+
error = ath_pci_init();
if (error < 0) {
printk(KERN_ERR
"ath9k: No PCI devices found, driver not installed.\n");
error = -ENODEV;
- goto err_rate_unregister;
+ goto err_remove_root;
}
error = ath_ahb_init();
@@ -2731,6 +2739,8 @@ static int __init ath9k_init(void)
err_pci_exit:
ath_pci_exit();
+ err_remove_root:
+ ath9k_debug_remove_root();
err_rate_unregister:
ath_rate_control_unregister();
err_out:
@@ -2742,6 +2752,7 @@ static void __exit ath9k_exit(void)
{
ath_ahb_exit();
ath_pci_exit();
+ ath9k_debug_remove_root();
ath_rate_control_unregister();
printk(KERN_INFO "%s: Driver unloaded\n", dev_info);
}
--
1.5.3.2
^ permalink raw reply related
* [ath9k-devel] [PATCH] ath9k: create a common debugfs_root for all device instances
From: Gabor Juhos @ 2009-03-05 15:55 UTC (permalink / raw)
To: ath9k-devel
The driver are trying to create an 'ath9k' directory in debugfs for each
device currently. If there are more than one device in the system, the
second try will always fail.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
---
drivers/net/wireless/ath9k/debug.c | 24 ++++++++++++++++++------
drivers/net/wireless/ath9k/debug.h | 12 +++++++++++-
drivers/net/wireless/ath9k/main.c | 13 ++++++++++++-
3 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath9k/debug.c b/drivers/net/wireless/ath9k/debug.c
index 0c422c5..3b645ee 100644
--- a/drivers/net/wireless/ath9k/debug.c
+++ b/drivers/net/wireless/ath9k/debug.c
@@ -19,6 +19,8 @@
static unsigned int ath9k_debug = DBG_DEFAULT;
module_param_named(debug, ath9k_debug, uint, 0);
+static struct dentry *ath9k_debugfs_root;
+
void DPRINTF(struct ath_softc *sc, int dbg_mask, const char *fmt, ...)
{
if (!sc)
@@ -334,12 +336,8 @@ int ath9k_init_debug(struct ath_softc *sc)
{
sc->debug.debug_mask = ath9k_debug;
- sc->debug.debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
- if (!sc->debug.debugfs_root)
- goto err;
-
sc->debug.debugfs_phy = debugfs_create_dir(wiphy_name(sc->hw->wiphy),
- sc->debug.debugfs_root);
+ ath9k_debugfs_root);
if (!sc->debug.debugfs_phy)
goto err;
@@ -374,5 +372,19 @@ void ath9k_exit_debug(struct ath_softc *sc)
debugfs_remove(sc->debug.debugfs_interrupt);
debugfs_remove(sc->debug.debugfs_dma);
debugfs_remove(sc->debug.debugfs_phy);
- debugfs_remove(sc->debug.debugfs_root);
+}
+
+int ath9k_debug_create_root(void)
+{
+ ath9k_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
+ if (!ath9k_debugfs_root)
+ return -ENOENT;
+
+ return 0;
+}
+
+void ath9k_debug_remove_root(void)
+{
+ debugfs_remove(ath9k_debugfs_root);
+ ath9k_debugfs_root = NULL;
}
diff --git a/drivers/net/wireless/ath9k/debug.h b/drivers/net/wireless/ath9k/debug.h
index 01681f2..89ba818 100644
--- a/drivers/net/wireless/ath9k/debug.h
+++ b/drivers/net/wireless/ath9k/debug.h
@@ -102,7 +102,6 @@ struct ath_stats {
struct ath9k_debug {
int debug_mask;
- struct dentry *debugfs_root;
struct dentry *debugfs_phy;
struct dentry *debugfs_dma;
struct dentry *debugfs_interrupt;
@@ -113,6 +112,8 @@ struct ath9k_debug {
void DPRINTF(struct ath_softc *sc, int dbg_mask, const char *fmt, ...);
int ath9k_init_debug(struct ath_softc *sc);
void ath9k_exit_debug(struct ath_softc *sc);
+int ath9k_debug_create_root(void);
+void ath9k_debug_remove_root(void);
void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status);
void ath_debug_stat_rc(struct ath_softc *sc, struct sk_buff *skb);
void ath_debug_stat_retries(struct ath_softc *sc, int rix,
@@ -134,6 +135,15 @@ static inline void ath9k_exit_debug(struct ath_softc *sc)
{
}
+static inline int ath9k_debug_create_root(void)
+{
+ return 0;
+}
+
+static inline void ath9k_debug_remove_root(void)
+{
+}
+
static inline void ath_debug_stat_interrupt(struct ath_softc *sc,
enum ath9k_int status)
{
diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k/main.c
index 28200ce..d37924a 100644
--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -2712,12 +2712,20 @@ static int __init ath9k_init(void)
goto err_out;
}
+ error = ath9k_debug_create_root();
+ if (error) {
+ printk(KERN_ERR
+ "ath9k: Unable to create debugfs root: %d\n",
+ error);
+ goto err_rate_unregister;
+ }
+
error = ath_pci_init();
if (error < 0) {
printk(KERN_ERR
"ath9k: No PCI devices found, driver not installed.\n");
error = -ENODEV;
- goto err_rate_unregister;
+ goto err_remove_root;
}
error = ath_ahb_init();
@@ -2731,6 +2739,8 @@ static int __init ath9k_init(void)
err_pci_exit:
ath_pci_exit();
+ err_remove_root:
+ ath9k_debug_remove_root();
err_rate_unregister:
ath_rate_control_unregister();
err_out:
@@ -2742,6 +2752,7 @@ static void __exit ath9k_exit(void)
{
ath_ahb_exit();
ath_pci_exit();
+ ath9k_debug_remove_root();
ath_rate_control_unregister();
printk(KERN_INFO "%s: Driver unloaded\n", dev_info);
}
--
1.5.3.2
^ permalink raw reply related
* where is "struct constraint_id" defined?
From: david.hagood @ 2009-03-05 15:54 UTC (permalink / raw)
To: linux-omap
I am trying to build the OMAP3 graphics kernel module against
2.6.29-rc7-omap1 (from GIT), and have been running into problems getting
it to build.
Two problems were pretty easy: the TI code was including "asm/resource.h"
and "asm/semaphore.h" rather than "linux/resource.h" and
"linux/semaphore.h".
Having made those changes, it builds all the way through to the TI
supplied "sysutils_linux.c", which barfs with :
In file included from
/space/src/OMAP35x_Graphics_SDC_3_00_00_06/GFX_Linux_KM/services4/srvkm/env/linux/kbuild/../../../../../services4/system/omap3430/sysutils.c:28:
/space/src/OMAP35x_Graphics_SDC_3_00_00_06/GFX_Linux_KM/services4/srvkm/env/linux/kbuild/../../../../../services4/system/omap3430/sysutils_linux.c:154:
error: variable 'cnstr_id_vdd2' has initializer but incomplete type
(and many other errors).
The problem line of the code is:
static struct constraint_id cnstr_id_vdd2 = {
and I cannot find a definition of "struct constraint_id" anywhere in the
kernel.
Has this been renamed, or moved, or am I looking in the wrong place?
^ permalink raw reply
* [refpolicy] admin_netutils.patch
From: Daniel J Walsh @ 2009-03-05 15:53 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_netutils.patch
ping looks at system state, tends to have it stdout redirected to log
files and pipes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv9YAACgkQrlYvE4MpobMT7QCg4oGKGwROQGU81BX+qK7HtRGh
a/0AmwTK85fsiyHcNawZOgTK8Py+NwAe
=cT1e
-----END PGP SIGNATURE-----
^ permalink raw reply
* [linux-lvm] LVM partition type
From: Tejas Sumant @ 2009-03-05 15:53 UTC (permalink / raw)
To: linux-lvm
Hi there,
I created a physical volume using pvcreate command on /dev/sda. When I
checked the partition entries in MBR for /dev/sda using fdisk observed
that no partitions were displayed.
Why pvcreate doesnt make partition entry with type 8e in MBR? Which
partition entry gets used in case whole disk is made PV?
--
Tejas Sumant
^ permalink raw reply
* [refpolicy] admin_mrtg.patch
From: Daniel J Walsh @ 2009-03-05 15:52 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_mrtg.patch
Dontaudit listing of /root
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv9UkACgkQrlYvE4MpobPpyACgka5FiVatoehqMCD8LLrVKZGX
WGwAn3QWy+djDDCLzAMYkxtp2+saBKh0
=tVsR
-----END PGP SIGNATURE-----
^ permalink raw reply
* [refpolicy] admin_logwatch.patch
From: Daniel J Walsh @ 2009-03-05 15:52 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_logwatch.patch
logwatch reads network sysctls and network state.
Reads symbolic links in var
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv9TAACgkQrlYvE4MpobN3dACgz1v6qldU3lONZDZnke+D+5DP
NFcAoIEdBF81CY6U/tbgPqHt8AWDX0kO
=AHaH
-----END PGP SIGNATURE-----
^ permalink raw reply
* [refpolicy] admin_logrotate.patch
From: Daniel J Walsh @ 2009-03-05 15:51 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_logrotate.patch
logrotate actually executes squid
logrotate can rotate logs in the users directories.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv9QMACgkQrlYvE4MpobOGIgCaAxwX4MpFC11ltrfcytlEjfqp
9h8AoNRtfDb9a+hMYwtszGUOn9uoTyq/
=Pchh
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] MX1 fix include
From: Paulius Zaleckas @ 2009-03-05 15:51 UTC (permalink / raw)
To: Darius; +Cc: linux-arm-kernel, Sascha Hauer, linux-kernel
In-Reply-To: <499ACF91.1070003@gmail.com>
Darius wrote:
> Sascha Hauer wrote:
>> On Mon, Jan 12, 2009 at 04:22:57PM +0200, Darius wrote:
>>> From: Darius Augulis <augulis.darius@gmail.com>
>>>
>>> Includes missed irqs.h in devices.c and mx1ads.c.
>> Looks good, thanks.
>
> Hi Sascha,
>
> probably you forgot to merge this in next rc (2), please do this ASAP in next rc, if possible.
Hi Sasha,
Will you submit this patch upstream?
It is definitely 2.6.29 material since it is not possible to compile MX1 without it!
Paulius Zaleckas
> BR,
> Darius
>
>> BTW do you plan to integrate the missing pieces from arch-imx into
>> arch-mx1, like SDHC and framebuffer? I think we should add these before
>> removing arch-imx.
>>
>> Sascha
>>
>>> Signed-off-by: Darius Augulis <augulis.darius@gmail.com>
>>>
>>> Index: linux-2.6.29-rc1/arch/arm/mach-mx1/devices.c
>>> ===================================================================
>>> --- linux-2.6.29-rc1.orig/arch/arm/mach-mx1/devices.c
>>> +++ linux-2.6.29-rc1/arch/arm/mach-mx1/devices.c
>>> @@ -23,6 +23,8 @@
>>> #include <linux/init.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/gpio.h>
>>> +
>>> +#include <mach/irqs.h>
>>> #include <mach/hardware.h>
>>>
>>> static struct resource imx_csi_resources[] = {
>>> Index: linux-2.6.29-rc1/arch/arm/mach-mx1/mx1ads.c
>>> ===================================================================
>>> --- linux-2.6.29-rc1.orig/arch/arm/mach-mx1/mx1ads.c
>>> +++ linux-2.6.29-rc1/arch/arm/mach-mx1/mx1ads.c
>>> @@ -21,6 +21,7 @@
>>> #include <asm/mach/arch.h>
>>> #include <asm/mach/time.h>
>>>
>>> +#include <mach/irqs.h>
>>> #include <mach/hardware.h>
>>> #include <mach/common.h>
>>> #include <mach/imx-uart.h>
>>> -------------------------------------------------------------------
>>> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
>>> FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
>>> Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>
>
>
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
>
^ permalink raw reply
* Re: [git-pull -tip] x86: msr architecture debug code
From: Jaswinder Singh Rajput @ 2009-03-05 15:47 UTC (permalink / raw)
To: Andreas Herrmann; +Cc: Ingo Molnar, H. Peter Anvin, x86 maintainers, LKML
In-Reply-To: <20090305143726.GC7347@alberich.amd.com>
On Thu, 2009-03-05 at 15:37 +0100, Andreas Herrmann wrote:
> On Thu, Mar 05, 2009 at 07:42:26PM +0530, Jaswinder Singh Rajput wrote:
> > On Thu, 2009-03-05 at 14:54 +0100, Andreas Herrmann wrote:
> >
> > > All nice suggestions but why in-kernel?
> > >
> >
> > In Kernel Space:
> >
> > We can read/write MSRs and can change the bits and see it effect without
> > writing any code.
>
> Sorry, I can't (or maybe I don't like to) follow.
>
> (BTW, you don't even need to write C-code. You can use a one-liner in perl
> or python to seek and read any MSR using /dev/cpu/*/msr.)
>
You are running these commands on shell when every thing is working.
What you will do if you are not getting the shell and kernel is dumping
or rebooting before that.
--
JSR
^ permalink raw reply
* [refpolicy] admin_consoletype.patch
From: Daniel J Walsh @ 2009-03-05 15:47 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_consoletype.patch
Consoletype wants to ssy_tty_config, and to list inotify
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv9C0ACgkQrlYvE4MpobMsUgCcCJZVex+IWotafzSjHjSVitVG
eIMAn1E7SLSIVkSTevrKuHigwc88Lapr
=GEuu
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] lm90: Support the MAX6648/6692 chips
From: Darrick J. Wong @ 2009-03-05 15:47 UTC (permalink / raw)
To: Jean Delvare; +Cc: Andrew Morton, linux-kernel, lm-sensors
In-Reply-To: <20090305152517.4e0b8983@hyperion.delvare>
On Thu, Mar 05, 2009 at 03:25:17PM +0100, Jean Delvare wrote:
> Hi Darrick
> I am confused. According to my notes, the MAX6648/MAX6692 is the same
> chip as the MAX6646/MAX6647/MAX6649 (same chip ID of 0x59), the only
> difference being the I2C address (0x4c for the MAX6646, 0x4e for the
> MAX6647 and 0x4d for the MAX6648/MAX6649/MAX6692). So the current code
> should _already_ detect your MAX6648 or MAX6692 as kind = max6646.
Heh, yep, it does. I guess this patch has been sitting around long
enough to become obsolete, sorry for the unnecessary mail traffic. I
guess we can drop this one.
> Can you please test the latest version of the sensors-detect script [1]
> and let me know if your chip is properly detected? If not, please
> provide a dump of your chip.
Just for fun, here's a dump of that chip (6648):
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 15 1d 00 00 05 69 00 6e 05 05 05 05 05 05 05 05 ??..?i.n????????
10: e0 c0 c0 c0 c0 c0 c0 c0 00 91 91 91 91 91 91 91 ????????.???????
20: 91 0a 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
30: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
40: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
50: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
60: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
70: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
80: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
90: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
a0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
b0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
c0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
d0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
e0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
f0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 4d 59 ??????????????MY
> [1] http://www.lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
This also detects it properly.
--D
^ permalink raw reply
* Re: [lm-sensors] [PATCH] lm90: Support the MAX6648/6692 chips
From: Darrick J. Wong @ 2009-03-05 15:47 UTC (permalink / raw)
To: Jean Delvare; +Cc: Andrew Morton, linux-kernel, lm-sensors
In-Reply-To: <20090305152517.4e0b8983@hyperion.delvare>
On Thu, Mar 05, 2009 at 03:25:17PM +0100, Jean Delvare wrote:
> Hi Darrick
> I am confused. According to my notes, the MAX6648/MAX6692 is the same
> chip as the MAX6646/MAX6647/MAX6649 (same chip ID of 0x59), the only
> difference being the I2C address (0x4c for the MAX6646, 0x4e for the
> MAX6647 and 0x4d for the MAX6648/MAX6649/MAX6692). So the current code
> should _already_ detect your MAX6648 or MAX6692 as kind = max6646.
Heh, yep, it does. I guess this patch has been sitting around long
enough to become obsolete, sorry for the unnecessary mail traffic. I
guess we can drop this one.
> Can you please test the latest version of the sensors-detect script [1]
> and let me know if your chip is properly detected? If not, please
> provide a dump of your chip.
Just for fun, here's a dump of that chip (6648):
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 15 1d 00 00 05 69 00 6e 05 05 05 05 05 05 05 05 ??..?i.n????????
10: e0 c0 c0 c0 c0 c0 c0 c0 00 91 91 91 91 91 91 91 ????????.???????
20: 91 0a 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
30: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
40: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
50: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
60: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
70: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
80: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
90: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
a0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
b0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
c0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
d0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
e0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 ????????????????
f0: 86 86 86 86 86 86 86 86 86 86 86 86 86 86 4d 59 ??????????????MY
> [1] http://www.lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
This also detects it properly.
--D
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [refpolicy] admin_certwatch.patch
From: Daniel J Walsh @ 2009-03-05 15:47 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_certwatch.patch
Certwatch uses auth cache
Reads apache config
Dontaudit listing of /root
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv9AQACgkQrlYvE4MpobMDigCgyigZCQ/q6JEf3+zlVJN+tJMr
6RsAn1buNUdIedeURMLAdeVFskpgTCna
=ApRs
-----END PGP SIGNATURE-----
^ permalink raw reply
* [refpolicy] admin_alsa.patch
From: Daniel J Walsh @ 2009-03-05 15:45 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://people.fedoraproject.org/~dwalsh/SELinux/F11/admin_alsa.patch
Reads sysfs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmv85UACgkQrlYvE4MpobMHAQCg3NlIBixLzRtDegjnNOKzk2Ar
Bp8An1OtWv0IaqRtuAyOB8EB/GzyIeuY
=MX2x
-----END PGP SIGNATURE-----
^ permalink raw reply
* [Cluster-devel] GFS2: Clean up of glops.c
From: Steven Whitehouse @ 2009-03-05 15:43 UTC (permalink / raw)
To: cluster-devel.redhat.com
This cleans up a number of bits of code mostly based in glops.c.
A couple of simple functions have been merged into the callers
to make it more obvious what is going on, the mysterious raising
of i_writecount around the truncate_inode_pages() call has been
removed. The meta_go_* operations have been renamed rgrp_go_*
since that is the only lock type that they are used with.
The unused argument of gfs2_read_sb has been removed. Also
a bug has been fixed where a check for the rindex inode was
in the wrong callback. More comments are added, and the
debugging code is improved too.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index f34bc70..bf23a62 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2/glops.c
@@ -76,29 +76,7 @@ static void gfs2_ail_empty_gl(struct gfs2_glock *gl)
}
/**
- * gfs2_pte_inval - Sync and invalidate all PTEs associated with a glock
- * @gl: the glock
- *
- */
-
-static void gfs2_pte_inval(struct gfs2_glock *gl)
-{
- struct gfs2_inode *ip;
- struct inode *inode;
-
- ip = gl->gl_object;
- inode = &ip->i_inode;
- if (!ip || !S_ISREG(inode->i_mode))
- return;
-
- unmap_shared_mapping_range(inode->i_mapping, 0, 0);
- if (test_bit(GIF_SW_PAGED, &ip->i_flags))
- set_bit(GLF_DIRTY, &gl->gl_flags);
-
-}
-
-/**
- * meta_go_sync - sync out the metadata for this glock
+ * rgrp_go_sync - sync out the metadata for this glock
* @gl: the glock
*
* Called when demoting or unlocking an EX glock. We must flush
@@ -106,36 +84,42 @@ static void gfs2_pte_inval(struct gfs2_glock *gl)
* not return to caller to demote/unlock the glock until I/O is complete.
*/
-static void meta_go_sync(struct gfs2_glock *gl)
+static void rgrp_go_sync(struct gfs2_glock *gl)
{
- if (gl->gl_state != LM_ST_EXCLUSIVE)
+ struct address_space *metamapping = gl->gl_aspace->i_mapping;
+ int error;
+
+ if (!test_and_clear_bit(GLF_DIRTY, &gl->gl_flags))
return;
+ BUG_ON(gl->gl_state != LM_ST_EXCLUSIVE);
- if (test_and_clear_bit(GLF_DIRTY, &gl->gl_flags)) {
- gfs2_log_flush(gl->gl_sbd, gl);
- gfs2_meta_sync(gl);
- gfs2_ail_empty_gl(gl);
- }
+ gfs2_log_flush(gl->gl_sbd, gl);
+ filemap_fdatawrite(metamapping);
+ error = filemap_fdatawait(metamapping);
+ mapping_set_error(metamapping, error);
+ gfs2_ail_empty_gl(gl);
}
/**
- * meta_go_inval - invalidate the metadata for this glock
+ * rgrp_go_inval - invalidate the metadata for this glock
* @gl: the glock
* @flags:
*
+ * We never used LM_ST_DEFERRED with resource groups, so that we
+ * should always see the metadata flag set here.
+ *
*/
-static void meta_go_inval(struct gfs2_glock *gl, int flags)
+static void rgrp_go_inval(struct gfs2_glock *gl, int flags)
{
- if (!(flags & DIO_METADATA))
- return;
+ struct address_space *mapping = gl->gl_aspace->i_mapping;
- gfs2_meta_inval(gl);
- if (gl->gl_object == GFS2_I(gl->gl_sbd->sd_rindex))
- gl->gl_sbd->sd_rindex_uptodate = 0;
- else if (gl->gl_ops == &gfs2_rgrp_glops && gl->gl_object) {
- struct gfs2_rgrpd *rgd = (struct gfs2_rgrpd *)gl->gl_object;
+ BUG_ON(!(flags & DIO_METADATA));
+ gfs2_assert_withdraw(gl->gl_sbd, !atomic_read(&gl->gl_ail_count));
+ truncate_inode_pages(mapping, 0);
+ if (gl->gl_object) {
+ struct gfs2_rgrpd *rgd = (struct gfs2_rgrpd *)gl->gl_object;
rgd->rd_flags &= ~GFS2_RDF_UPTODATE;
}
}
@@ -152,48 +136,54 @@ static void inode_go_sync(struct gfs2_glock *gl)
struct address_space *metamapping = gl->gl_aspace->i_mapping;
int error;
- if (gl->gl_state != LM_ST_UNLOCKED)
- gfs2_pte_inval(gl);
- if (gl->gl_state != LM_ST_EXCLUSIVE)
- return;
-
if (ip && !S_ISREG(ip->i_inode.i_mode))
ip = NULL;
+ if (ip && test_and_clear_bit(GIF_SW_PAGED, &ip->i_flags))
+ unmap_shared_mapping_range(ip->i_inode.i_mapping, 0, 0);
+ if (!test_and_clear_bit(GLF_DIRTY, &gl->gl_flags))
+ return;
- if (test_bit(GLF_DIRTY, &gl->gl_flags)) {
- gfs2_log_flush(gl->gl_sbd, gl);
- filemap_fdatawrite(metamapping);
- if (ip) {
- struct address_space *mapping = ip->i_inode.i_mapping;
- filemap_fdatawrite(mapping);
- error = filemap_fdatawait(mapping);
- mapping_set_error(mapping, error);
- }
- error = filemap_fdatawait(metamapping);
- mapping_set_error(metamapping, error);
- clear_bit(GLF_DIRTY, &gl->gl_flags);
- gfs2_ail_empty_gl(gl);
+ BUG_ON(gl->gl_state != LM_ST_EXCLUSIVE);
+
+ gfs2_log_flush(gl->gl_sbd, gl);
+ filemap_fdatawrite(metamapping);
+ if (ip) {
+ struct address_space *mapping = ip->i_inode.i_mapping;
+ filemap_fdatawrite(mapping);
+ error = filemap_fdatawait(mapping);
+ mapping_set_error(mapping, error);
}
+ error = filemap_fdatawait(metamapping);
+ mapping_set_error(metamapping, error);
+ gfs2_ail_empty_gl(gl);
}
/**
* inode_go_inval - prepare a inode glock to be released
* @gl: the glock
* @flags:
+ *
+ * Normally we invlidate everything, but if we are moving into
+ * LM_ST_DEFERRED from LM_ST_SHARED or LM_ST_EXCLUSIVE then we
+ * can keep hold of the metadata, since it won't have changed.
*
*/
static void inode_go_inval(struct gfs2_glock *gl, int flags)
{
struct gfs2_inode *ip = gl->gl_object;
- int meta = (flags & DIO_METADATA);
- if (meta) {
- gfs2_meta_inval(gl);
+ gfs2_assert_withdraw(gl->gl_sbd, !atomic_read(&gl->gl_ail_count));
+
+ if (flags & DIO_METADATA) {
+ struct address_space *mapping = gl->gl_aspace->i_mapping;
+ truncate_inode_pages(mapping, 0);
if (ip)
set_bit(GIF_INVALID, &ip->i_flags);
}
+ if (ip == GFS2_I(gl->gl_sbd->sd_rindex))
+ gl->gl_sbd->sd_rindex_uptodate = 0;
if (ip && S_ISREG(ip->i_inode.i_mode))
truncate_inode_pages(ip->i_inode.i_mapping, 0);
}
@@ -395,7 +385,6 @@ static int trans_go_demote_ok(const struct gfs2_glock *gl)
}
const struct gfs2_glock_operations gfs2_meta_glops = {
- .go_xmote_th = meta_go_sync,
.go_type = LM_TYPE_META,
};
@@ -410,8 +399,8 @@ const struct gfs2_glock_operations gfs2_inode_glops = {
};
const struct gfs2_glock_operations gfs2_rgrp_glops = {
- .go_xmote_th = meta_go_sync,
- .go_inval = meta_go_inval,
+ .go_xmote_th = rgrp_go_sync,
+ .go_inval = rgrp_go_inval,
.go_demote_ok = rgrp_go_demote_ok,
.go_lock = rgrp_go_lock,
.go_unlock = rgrp_go_unlock,
diff --git a/fs/gfs2/meta_io.c b/fs/gfs2/meta_io.c
index 870d65a..8d6f132 100644
--- a/fs/gfs2/meta_io.c
+++ b/fs/gfs2/meta_io.c
@@ -89,27 +89,6 @@ void gfs2_aspace_put(struct inode *aspace)
}
/**
- * gfs2_meta_inval - Invalidate all buffers associated with a glock
- * @gl: the glock
- *
- */
-
-void gfs2_meta_inval(struct gfs2_glock *gl)
-{
- struct gfs2_sbd *sdp = gl->gl_sbd;
- struct inode *aspace = gl->gl_aspace;
- struct address_space *mapping = gl->gl_aspace->i_mapping;
-
- gfs2_assert_withdraw(sdp, !atomic_read(&gl->gl_ail_count));
-
- atomic_inc(&aspace->i_writecount);
- truncate_inode_pages(mapping, 0);
- atomic_dec(&aspace->i_writecount);
-
- gfs2_assert_withdraw(sdp, !mapping->nrpages);
-}
-
-/**
* gfs2_meta_sync - Sync all buffers associated with a glock
* @gl: The glock
*
diff --git a/fs/gfs2/meta_io.h b/fs/gfs2/meta_io.h
index b1a5f36..de270c2 100644
--- a/fs/gfs2/meta_io.h
+++ b/fs/gfs2/meta_io.h
@@ -40,7 +40,6 @@ static inline void gfs2_buffer_copy_tail(struct buffer_head *to_bh,
struct inode *gfs2_aspace_get(struct gfs2_sbd *sdp);
void gfs2_aspace_put(struct inode *aspace);
-void gfs2_meta_inval(struct gfs2_glock *gl);
void gfs2_meta_sync(struct gfs2_glock *gl);
struct buffer_head *gfs2_meta_new(struct gfs2_glock *gl, u64 blkno);
diff --git a/fs/gfs2/ops_file.c b/fs/gfs2/ops_file.c
index 99d726f..48ec3d5 100644
--- a/fs/gfs2/ops_file.c
+++ b/fs/gfs2/ops_file.c
@@ -355,7 +355,6 @@ static int gfs2_page_mkwrite(struct vm_area_struct *vma, struct page *page)
if (ret)
goto out;
- set_bit(GIF_SW_PAGED, &ip->i_flags);
ret = gfs2_write_alloc_required(ip, pos, PAGE_CACHE_SIZE, &alloc_required);
if (ret || !alloc_required)
goto out_unlock;
@@ -396,6 +395,8 @@ static int gfs2_page_mkwrite(struct vm_area_struct *vma, struct page *page)
goto out_unlock_page;
}
ret = gfs2_allocate_page_backing(page);
+ if (!ret)
+ set_bit(GIF_SW_PAGED, &ip->i_flags);
out_unlock_page:
unlock_page(page);
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index 804ca72..51883b3 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -296,15 +296,15 @@ static int gfs2_read_super(struct gfs2_sbd *sdp, sector_t sector)
__free_page(page);
return 0;
}
+
/**
* gfs2_read_sb - Read super block
* @sdp: The GFS2 superblock
- * @gl: the glock for the superblock (assumed to be held)
* @silent: Don't print message if mount fails
*
*/
-static int gfs2_read_sb(struct gfs2_sbd *sdp, struct gfs2_glock *gl, int silent)
+static int gfs2_read_sb(struct gfs2_sbd *sdp, int silent)
{
u32 hash_blocks, ind_blocks, leaf_blocks;
u32 tmp_blocks;
@@ -524,7 +524,7 @@ static int init_sb(struct gfs2_sbd *sdp, int silent)
return ret;
}
- ret = gfs2_read_sb(sdp, sb_gh.gh_gl, silent);
+ ret = gfs2_read_sb(sdp, silent);
if (ret) {
fs_err(sdp, "can't read superblock: %d\n", ret);
goto out;
^ permalink raw reply related
* Re: [RFC][PATCH] irq: remove IRQF_DISABLED
From: Mark Lord @ 2009-03-05 15:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Vadim Lobanov, Peter Zijlstra, Ingo Molnar, Thomas Gleixner, lkml,
linux-arch, Andrew Morton
In-Reply-To: <alpine.LFD.2.00.0903021048570.3111@localhost.localdomain>
Linus Torvalds wrote:
>
> Although it porbably does mean that the problem tends to be more in the
> really bad mode0 case (600ns -> 150us/sector -> milliseconds for
> multi-sector transfers).
..
Heh.. it's worse that that: even with commonplace mode4 (120ns) transfers,
each PCI bus transaction from start to finish often takes about 1us,
so for a 16-sector multi-sector read, that means 4ms+ with interrupts off.
> I forget what our multi-sector limit is, I think it tends to be 16. So
> you'll never get _really_ long irq-off times, but "several ms" is still
> pretty damn bad.
..
It's a device limit, usually 8 or 16 sectors for nearly all drives now.
Cheers
^ permalink raw reply
* [PATCH] libata: add CFA specific identify data words
From: Jeff Garzik @ 2009-03-05 15:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Andrew Morton, Linus Torvalds, sshtylyov, linux-ide, LKML
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Declare and use constants for CFA specific identify data words 162 and 163.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
---
Sergei said:
This patch is against the current pata-2.6 series. I'd prefer that Bart merged
it thru his tree as my next patch adding CF mode support to IDE depends on it.
jgarzik adds:
I didn't see this in your latest submission, Bart. It is simple and
harmless and might as well go ahead upstream, to eliminate the
cross-tree dependency that Sergei speaks of (his patch also touched
drivers/ata/libata-core.c, but I excluded that from below).
include/linux/ata.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Index: linux-2.6/include/linux/ata.h
===================================================================
--- linux-2.6.orig/include/linux/ata.h
+++ linux-2.6/include/linux/ata.h
@@ -89,6 +89,8 @@ enum {
ATA_ID_DLF = 128,
ATA_ID_CSFO = 129,
ATA_ID_CFA_POWER = 160,
+ ATA_ID_CFA_KEY_MGMT = 162,
+ ATA_ID_CFA_MODES = 163,
ATA_ID_ROT_SPEED = 217,
ATA_ID_PIO4 = (1 << 1),
^ permalink raw reply
* Re: [RFC] renaming packages/ to recipes/
From: Otavio Salvador @ 2009-03-05 15:35 UTC (permalink / raw)
To: openembedded-devel; +Cc: openembedded-devel
In-Reply-To: <golnv0$h4r$1@ger.gmane.org>
Koen Kooi <k.kooi@student.utwente.nl> writes:
> On 25-02-09 21:21, Koen Kooi wrote:
>> Hi,
>>
>> I keep trying to teach people the difference between recipes (what's in
>> OE) and packages (what you install on the target) and keep getting
>> reactions like "ok, but why is the dir called packages?", which are
>> completely valid.
>>
>> Proposal:
>>
>> mv packages recipes ; git commit .
>
> Only positive replies sofar, so when do we want to schedule this
> commit? My proposal is somewhere in april, since I'm too busy this
> month with bossaconference and university work to deal with the
> fallout properly.
> Also, shall we restructure TMPDIR at the same time?
[...]
Let's do it step by step. It is much easier and nicer to our users if
they don't have to handle a completely different tree to get theirs work
done.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.