* [Qemu-devel] Re: [PATCH 09/11] i386: avoid a write only variable
From: Blue Swirl @ 2010-10-07 17:32 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4CAD7657.8080400@redhat.com>
On Thu, Oct 7, 2010 at 7:27 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 10/06/2010 11:34 PM, Blue Swirl wrote:
>>
>> Compiling with GCC 4.6.0 20100925 produced warnings:
>> /src/qemu/target-i386/op_helper.c: In function 'switch_tss':
>> /src/qemu/target-i386/op_helper.c:283:53: error: variable 'new_trap'
>> set but not used [-Werror=unused-but-set-variable]
>>
>> Fix by deleting the variable.
>
> Again, this warning tells us the emulation is incorrect, so it's wrong to
> remove it.
The warning tells us that the emulation is unfinished.
It's probably unfinished because debugging TSS switches hasn't ever
been needed by anyone. If anyone in the future cares enough about T
bit, it's easy to implement it even after this part has been removed.
But if someone proposes a better patch, I'd be happy to use that
instead of this.
^ permalink raw reply
* Re: Issue : jffs2 and ecc layout
From: Vimal Singh @ 2010-10-07 17:31 UTC (permalink / raw)
To: Ghorai, Sukumar; +Cc: linux-omap@vger.kernel.org, linux-mtd@lists.infradead.org
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B0356594397@dbde02.ent.ti.com>
On Mon, Oct 4, 2010 at 12:59 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>
>
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Ghorai, Sukumar
>> Sent: Tuesday, September 28, 2010 6:17 PM
>> To: linux-mtd@lists.infradead.org
>> Cc: linux-omap@vger.kernel.org
>> Subject: Issue : jffs2 and ecc layout
>>
>> Hi,
>> I was using the following ecc layout which is not working to mount the
>> jffs2 File-system. I was in 2.6.32 kernel and working; but same layout is
>> not working with latest 2.6 kernel.
>>
>> Observation is that - no read request issued to the driver (say omap2.c).
>>
>> # mount -t jffs2 /dev/mtdblock4 /mnt/nand
>> [ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes, read
>> 0 bytes, error -22
>> mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error
>>
>> # dmesg
>> <3>[ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes,
>> read 0 bytes, error -22
>>
I do not think above issue has anything to do with the ECC layout.
But as I earlier pointed (in [1]), this change [2] has messed up
function 'omap_hwcontrol'.
All read/write functions read/write data from/to address
info->nand.IO_ADDR_(R/W), which is not set by new function
'gpmc_nand_write' (which still take care of writing address/cmd to
write registers). But since above pointer is not set (hence points to
address '0'), driver tries to read data from wrong location.
In fact, I would even suggest to try dumping nand command registers(or
use T32) and verify if commands issued were written correctly to
appropriate registers.
[1]: http://marc.info/?l=linux-omap&m=128302624528822&w=2
[2] commit: http://git.infradead.org/mtd-2.6.git/commitdiff/2c01946c6b9ebaa5a89710bc42ca224a7f52f227
--
Regards,
Vimal Singh
^ permalink raw reply
* Re: Issue : jffs2 and ecc layout
From: Vimal Singh @ 2010-10-07 17:31 UTC (permalink / raw)
To: Ghorai, Sukumar; +Cc: linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B0356594397@dbde02.ent.ti.com>
On Mon, Oct 4, 2010 at 12:59 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>
>
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Ghorai, Sukumar
>> Sent: Tuesday, September 28, 2010 6:17 PM
>> To: linux-mtd@lists.infradead.org
>> Cc: linux-omap@vger.kernel.org
>> Subject: Issue : jffs2 and ecc layout
>>
>> Hi,
>> I was using the following ecc layout which is not working to mount the
>> jffs2 File-system. I was in 2.6.32 kernel and working; but same layout is
>> not working with latest 2.6 kernel.
>>
>> Observation is that - no read request issued to the driver (say omap2.c).
>>
>> # mount -t jffs2 /dev/mtdblock4 /mnt/nand
>> [ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes, read
>> 0 bytes, error -22
>> mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error
>>
>> # dmesg
>> <3>[ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes,
>> read 0 bytes, error -22
>>
I do not think above issue has anything to do with the ECC layout.
But as I earlier pointed (in [1]), this change [2] has messed up
function 'omap_hwcontrol'.
All read/write functions read/write data from/to address
info->nand.IO_ADDR_(R/W), which is not set by new function
'gpmc_nand_write' (which still take care of writing address/cmd to
write registers). But since above pointer is not set (hence points to
address '0'), driver tries to read data from wrong location.
In fact, I would even suggest to try dumping nand command registers(or
use T32) and verify if commands issued were written correctly to
appropriate registers.
[1]: http://marc.info/?l=linux-omap&m=128302624528822&w=2
[2] commit: http://git.infradead.org/mtd-2.6.git/commitdiff/2c01946c6b9ebaa5a89710bc42ca224a7f52f227
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Qemu-devel] [PATCH] Use '_raw' memory access primitives.
From: Lluís @ 2010-10-07 17:20 UTC (permalink / raw)
To: qemu-devel
Using a pointer on the host should not go through lduw.
Signed-off-by: Lluís <xscript@gmx.net>
---
linux-user/signal.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 77683f7..097da9d 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -982,8 +982,8 @@ restore_sigcontext(CPUX86State *env, struct target_sigcontext *sc, int *peax)
env->regs[R_ECX] = tswapl(sc->ecx);
env->eip = tswapl(sc->eip);
- cpu_x86_load_seg(env, R_CS, lduw(&sc->cs) | 3);
- cpu_x86_load_seg(env, R_SS, lduw(&sc->ss) | 3);
+ cpu_x86_load_seg(env, R_CS, lduw_raw(&sc->cs) | 3);
+ cpu_x86_load_seg(env, R_SS, lduw_raw(&sc->ss) | 3);
tmpflags = tswapl(sc->eflags);
env->eflags = (env->eflags & ~0x40DD5) | (tmpflags & 0x40DD5);
--
1.7.1
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
^ permalink raw reply related
* Re: [Qemu-devel] Load primitive in linux-user/signal.c
From: Lluís @ 2010-10-07 17:21 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <AANLkTi=xA_HdwFHfg-8u2mW9+wc7AQNp0L=VcK1q-AUT@mail.gmail.com>
Mulyadi Santosa writes:
> I know nothing about your patch, but I suggest to rewrite this post so
> it follows patch submission format e.g comment, signed off then the
> patch itself.... :)
> No offense, ok? :)
None taken. I've sent it again with (I suppose) the adequate format.
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 05/11] Delete write only variables
From: Blue Swirl @ 2010-10-07 17:24 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4CAD7670.10808@redhat.com>
On Thu, Oct 7, 2010 at 7:27 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 10/06/2010 11:32 PM, Blue Swirl wrote:
>>
>> @@ -91,8 +90,6 @@ static int vga_osi_call (CPUState *env)
>> env->gpr[3] = 0;
>> break;
>> case 39: /* video_ctrl */
>> - if (env->gpr[6] == 0 || env->gpr[6] == 1)
>> - vga_vbl_enabled = env->gpr[6];
>> env->gpr[3] = 0;
>> break;
>> case 47:
>
> NACK, this smells like an incomplete emulation.
Why would we care about unfinished temporary Mac-on-Linux hack for
video.x? Perhaps the correct fix is to remove vga_osi_call function
and env->osi_call field entirely.
^ permalink raw reply
* Re: [PATCH net-next] net: percpu net_device refcount
From: Stephen Hemminger @ 2010-10-07 17:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1286471555.2912.291.camel@edumazet-laptop>
On Thu, 07 Oct 2010 19:12:35 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> We tried very hard to remove all possible dev_hold()/dev_put() pairs in
> network stack, using RCU conversions.
>
> There is still an unavoidable device refcount change for every dst we
> create/destroy, and this can slow down some workloads (routers or some
> app servers)
>
> We can switch to a percpu refcount implementation, now dynamic per_cpu
> infrastructure is mature. On a 64 cpus machine, this consumes 256 bytes
> per device.
>
It makes sense, but what about 256 cores and 1024 Vlans?
That adds up to 4M of memory which is might be noticeable.
--
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Jeff King @ 2010-10-07 17:29 UTC (permalink / raw)
To: Kirill Likhodedov; +Cc: Johannes Sixt, git
In-Reply-To: <FF2FF369-0B1C-457E-A86E-8651BF0A82CB@jetbrains.com>
On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:
> Thanks for pointing that out.
> I confirm that on Mac OS X that happens for rev-list as well.
>
> # git log --pretty=format:foo%x00bar HEAD -1 | od -c
> 0000000 f o o \0 b a r
> 0000007
>
> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c
> 0000000 c o m m i t 2 3 6 0 1 a 2 c 3
> 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3
> 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n
> 0000060 f o o \n
> 0000064
Ugh. Even worse, it does print with --graph, which uses a slightly
different code path.
$ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A
* commit 81d866a6a213d5524ce389369377ba3529461e1b$
|\ foo^@bar$
I am inclined to call the rev-list behavior a bug, and the fix is
probably:
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index efe9360..3b2dca0 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
}
} else {
if (revs->commit_format != CMIT_FMT_USERFORMAT ||
- buf.len)
- printf("%s%c", buf.buf, info->hdr_termination);
+ buf.len) {
+ fwrite(buf.buf, 1, buf.len, stdout);
+ putchar(info->hdr_termination);
+ }
}
strbuf_release(&buf);
} else {
^ permalink raw reply related
* [PATCH 6/9] Fix problem with fscking of mounted filesystem
From: Alasdair G Kergon @ 2010-10-07 17:25 UTC (permalink / raw)
To: lvm-devel
In-Reply-To: <d1625c45c8e5f047113bc2f2af784e11e5e81249.1286460218.git.zkabelac@redhat.com>
On Thu, Oct 07, 2010 at 04:06:36PM +0200, Zdenek Kabelac wrote:
> Instead of calling mount without parameter to get actual mount table,
> switch to use /proc/mounts directly. (Not really sure, maybe we want to
> use /proc/self/mounts?)
/proc/mounts I'd think: If it's mounted anywhere on the system, we need to
be aware, even if it's not visible to the current process.
Alasdair
^ permalink raw reply
* Re: [PATCH 2/2] device-assignment: Allow PCI to manage the option ROM
From: Michael S. Tsirkin @ 2010-10-07 17:18 UTC (permalink / raw)
To: Alex Williamson; +Cc: kvm, ddutile, chrisw
In-Reply-To: <20101004212630.11167.93029.stgit@s20.home>
On Mon, Oct 04, 2010 at 03:26:30PM -0600, Alex Williamson wrote:
> We don't need to duplicate PCI code for mapping and managing the
> option ROM for an assigned device. We're already using an in-memory
> copy of the ROM, so we can simply fill the contents from the physical
> device and pass the rest off to PCI. As a benefit, we can now make
> use of the rombar and romfile options, which allow us to either hide
> the ROM BAR, or load it from an external file, such as we can do
> with emulated devices. This is useful if you want to pass through
> and boot from devices that are either missing a physical option ROM
> or don't supply a valid option ROM.
>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>
> hw/device-assignment.c | 155 +++++++++++++++++++++---------------------------
> hw/device-assignment.h | 4 +
> 2 files changed, 71 insertions(+), 88 deletions(-)
>
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 87f7418..26cb797 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -233,8 +233,6 @@ static CPUReadMemoryFunc * const slow_bar_read[] = {
> &slow_bar_readl
> };
>
> -static CPUWriteMemoryFunc * const slow_bar_null_write[] = {NULL, NULL, NULL};
> -
> static void assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> pcibus_t e_phys, pcibus_t e_size,
> int type)
> @@ -245,10 +243,7 @@ static void assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> int m;
>
> DEBUG("%s", "slow map\n");
> - if (region_num == PCI_ROM_SLOT)
> - m = cpu_register_io_memory(slow_bar_read, slow_bar_null_write, region);
> - else
> - m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region);
> + m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region);
> cpu_register_physical_memory(e_phys, e_size, m);
>
> /* MSI-X MMIO page */
> @@ -268,7 +263,7 @@ static void assigned_dev_iomem_map(PCIDevice *pci_dev, int region_num,
> AssignedDevice *r_dev = container_of(pci_dev, AssignedDevice, dev);
> AssignedDevRegion *region = &r_dev->v_addrs[region_num];
> PCIRegion *real_region = &r_dev->real_device.regions[region_num];
> - int ret = 0, flags = 0;
> + int ret = 0;
>
> DEBUG("e_phys=%08" FMT_PCIBUS " r_virt=%p type=%d len=%08" FMT_PCIBUS " region_num=%d \n",
> e_phys, region->u.r_virtbase, type, e_size, region_num);
> @@ -277,11 +272,7 @@ static void assigned_dev_iomem_map(PCIDevice *pci_dev, int region_num,
> region->e_size = e_size;
>
> if (e_size > 0) {
> -
> - if (region_num == PCI_ROM_SLOT)
> - flags |= IO_MEM_ROM;
> -
> - cpu_register_physical_memory(e_phys, e_size, region->memory_index | flags);
> + cpu_register_physical_memory(e_phys, e_size, region->memory_index);
>
> /* deal with MSI-X MMIO page */
> if (real_region->base_addr <= r_dev->msix_table_addr &&
> @@ -527,35 +518,22 @@ static int assigned_dev_register_regions(PCIRegion *io_regions,
> : PCI_BASE_ADDRESS_SPACE_MEMORY;
>
> if (cur_region->size & 0xFFF) {
> - if (i != PCI_ROM_SLOT) {
> - fprintf(stderr, "PCI region %d at address 0x%llx "
> - "has size 0x%x, which is not a multiple of 4K. "
> - "You might experience some performance hit "
> - "due to that.\n",
> - i, (unsigned long long)cur_region->base_addr,
> - cur_region->size);
> - }
> + fprintf(stderr, "PCI region %d at address 0x%llx "
> + "has size 0x%x, which is not a multiple of 4K. "
> + "You might experience some performance hit "
> + "due to that.\n",
> + i, (unsigned long long)cur_region->base_addr,
> + cur_region->size);
> slow_map = 1;
> }
>
> /* map physical memory */
> pci_dev->v_addrs[i].e_physbase = cur_region->base_addr;
> - if (i == PCI_ROM_SLOT) {
> - /* KVM doesn't support read-only mappings, use slow map */
> - slow_map = 1;
> - pci_dev->v_addrs[i].u.r_virtbase =
> - mmap(NULL,
> - cur_region->size,
> - PROT_WRITE | PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE,
> - 0, (off_t) 0);
> -
> - } else {
> - pci_dev->v_addrs[i].u.r_virtbase =
> - mmap(NULL,
> - cur_region->size,
> - PROT_WRITE | PROT_READ, MAP_SHARED,
> - cur_region->resource_fd, (off_t) 0);
> - }
> + pci_dev->v_addrs[i].u.r_virtbase = mmap(NULL, cur_region->size,
> + PROT_WRITE | PROT_READ,
> + MAP_SHARED,
> + cur_region->resource_fd,
> + (off_t)0);
>
> if (pci_dev->v_addrs[i].u.r_virtbase == MAP_FAILED) {
> pci_dev->v_addrs[i].u.r_virtbase = NULL;
> @@ -565,11 +543,6 @@ static int assigned_dev_register_regions(PCIRegion *io_regions,
> return -1;
> }
>
> - if (i == PCI_ROM_SLOT) {
> - memset(pci_dev->v_addrs[i].u.r_virtbase, 0,
> - (cur_region->size + 0xFFF) & 0xFFFFF000);
> - }
> -
> pci_dev->v_addrs[i].r_size = cur_region->size;
> pci_dev->v_addrs[i].e_size = 0;
>
> @@ -712,6 +685,12 @@ again:
> fprintf(stderr, "%s: read failed, errno = %d\n", __func__, errno);
> }
>
> + /* Clear host resource mapping info. If we choose not to register a
> + * BAR, such as might be the case with the option ROM, we can get
> + * confusing, unwritable, residual addresses from the host here. */
> + memset(&pci_dev->dev.config[PCI_BASE_ADDRESS_0], 0, 24);
> + memset(&pci_dev->dev.config[PCI_ROM_ADDRESS], 0, 4);
> +
> snprintf(name, sizeof(name), "%sresource", dir);
>
> f = fopen(name, "r");
> @@ -720,7 +699,7 @@ again:
> return 1;
> }
>
> - for (r = 0; r < PCI_NUM_REGIONS; r++) {
> + for (r = 0; r < PCI_ROM_SLOT; r++) {
> if (fscanf(f, "%lli %lli %lli\n", &start, &end, &flags) != 3)
> break;
>
> @@ -736,13 +715,11 @@ again:
> } else {
> flags &= ~IORESOURCE_PREFETCH;
> }
> - if (r != PCI_ROM_SLOT) {
> - snprintf(name, sizeof(name), "%sresource%d", dir, r);
> - fd = open(name, O_RDWR);
> - if (fd == -1)
> - continue;
> - rp->resource_fd = fd;
> - }
> + snprintf(name, sizeof(name), "%sresource%d", dir, r);
> + fd = open(name, O_RDWR);
> + if (fd == -1)
> + continue;
> + rp->resource_fd = fd;
>
> rp->type = flags;
> rp->valid = 1;
> @@ -1644,58 +1621,64 @@ void add_assigned_devices(PCIBus *bus, const char **devices, int n_devices)
> */
> static void assigned_dev_load_option_rom(AssignedDevice *dev)
> {
> - int size, len, ret;
> - void *buf;
> + char name[32], rom_file[64];
> FILE *fp;
> - uint8_t i = 1;
> - char rom_file[64];
> + uint8_t val;
> + struct stat st;
> + void *ptr;
> +
> + /* If loading ROM from file, pci handles it */
> + if (dev->dev.romfile || !dev->dev.rom_bar)
> + return;
>
> snprintf(rom_file, sizeof(rom_file),
> "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
> dev->host.seg, dev->host.bus, dev->host.dev, dev->host.func);
>
> - if (access(rom_file, F_OK))
> + if (stat(rom_file, &st)) {
> return;
> + }
>
Just a note that stat on the ROM sysfs file returns window size,
not the ROM size. So this allocates more ram than really necessary for
ROM. Real size is returned by fread.
Do we care?
> + ptr = qemu_get_ram_ptr(dev->dev.rom_offset);
> + memset(ptr, 0xff, st.st_size);
> +
> + if (!fread(ptr, 1, st.st_size, fp)) {
> + fprintf(stderr, "pci-assign: Cannot read from host %s\n"
> + "\tDevice option ROM contents are probably invalid "
> + "(check dmesg).\n\tSkip option ROM probe with rombar=0, "
> + "or load from file with romfile=\n", rom_file);
> + qemu_ram_free(dev->dev.rom_offset);
> + dev->dev.rom_offset = 0;
> + goto close_rom;
> }
>
> - if (!(ret = fread(buf, 1, size, fp))) {
> - free(buf);
> - fclose(fp);
> - return;
> + pci_register_bar(&dev->dev, PCI_ROM_SLOT,
> + st.st_size, 0, pci_map_option_rom);
> +close_rom:
> + /* Write "0" to disable ROM */
> + fseek(fp, 0, SEEK_SET);
> + val = 0;
> + if (!fwrite(&val, 1, 1, fp)) {
> + DEBUG("%s\n", "Failed to disable pci-sysfs rom file");
> }
> fclose(fp);
> -
> - /* The number of bytes read is often much smaller than the BAR size */
> - size = ret;
> -
> - /* Copy ROM contents into the space backing the ROM BAR */
> - if (dev->v_addrs[PCI_ROM_SLOT].r_size >= size &&
> - dev->v_addrs[PCI_ROM_SLOT].u.r_virtbase) {
> - memcpy(dev->v_addrs[PCI_ROM_SLOT].u.r_virtbase, buf, size);
> - }
> -
> - free(buf);
> }
> diff --git a/hw/device-assignment.h b/hw/device-assignment.h
> index 9a3ea12..2f5fa17 100644
> --- a/hw/device-assignment.h
> +++ b/hw/device-assignment.h
> @@ -57,7 +57,7 @@ typedef struct {
> uint16_t region_number; /* number of active regions */
>
> /* Port I/O or MMIO Regions */
> - PCIRegion regions[PCI_NUM_REGIONS];
> + PCIRegion regions[PCI_NUM_REGIONS - 1];
> int config_fd;
> } PCIDevRegions;
>
> @@ -80,7 +80,7 @@ typedef struct AssignedDevice {
> uint32_t use_iommu;
> int intpin;
> uint8_t debug_flags;
> - AssignedDevRegion v_addrs[PCI_NUM_REGIONS];
> + AssignedDevRegion v_addrs[PCI_NUM_REGIONS - 1];
> PCIDevRegions real_device;
> int run;
> int girq;
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> - /* Write something to the ROM file to enable it */
> - fp = fopen(rom_file, "wb");
> - if (fp == NULL)
> - return;
> - len = fwrite(&i, 1, 1, fp);
> - fclose(fp);
> - if (len != 1)
> + if (access(rom_file, F_OK)) {
> + fprintf(stderr, "pci-assign: Insufficient privileges for %s\n",
> + rom_file);
> return;
> + }
>
> - /* The file has to be closed and reopened, otherwise it won't work */
> - fp = fopen(rom_file, "rb");
> - if (fp == NULL)
> + /* Write "1" to the ROM file to enable it */
> + fp = fopen(rom_file, "r+");
> + if (fp == NULL) {
> return;
> -
> - fseek(fp, 0, SEEK_END);
> - size = ftell(fp);
> + }
> + val = 1;
> + if (fwrite(&val, 1, 1, fp) != 1) {
> + goto close_rom;
> + }
> fseek(fp, 0, SEEK_SET);
>
> - buf = malloc(size);
> - if (buf == NULL) {
> - fclose(fp);
> - return;
> + snprintf(name, sizeof(name), "%s.rom", dev->dev.qdev.info->name);
> + dev->dev.rom_offset = qemu_ram_alloc(&dev->dev.qdev, name, st.st_size);
^ permalink raw reply
* Re: Context settings after ssh login
From: Justin P. Mattock @ 2010-10-07 17:24 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Chad Sellers, imsand, selinux
In-Reply-To: <4CADF149.3040301@redhat.com>
On 10/07/2010 09:11 AM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/07/2010 10:40 AM, Chad Sellers wrote:
>> On 10/6/10 3:29 AM, "imsand@puzzle.ch"<imsand@puzzle.ch> wrote:
>>
>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>> Hello
>>>>>>>>>>>
>>>>>>>>>>> I'm working on SUSE SLES11SP1 and encounter the following problem.
>>>>>>>>>>> Setting the context of the User after ssh login doesn't work if
>>>>>>>>>>> the
>>>>>>>>>>> SELinux Username and the Linux Username aren't identical.
>>>>>>>>>>>
>>>>>>>>>>> --------------
>>>>>>>>>>> Here is an example (SElinux User=mat_u, Linux User=mat_u):
>>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]: Accepted
>>>>>>>>>>> keyboard-interactive/pam for mat_u from 131.102.233.125 port 54714
>>>>>>>>>>> ssh2
>>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> Open Session
>>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> Open Session
>>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> Username= mat_u SELinux User = user_u Level= (null)
>>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> set mat_u security context to user_u:user_r:user_t
>>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> set mat_u key creation context to user_u:user_r:user_t
>>>>>>>>>>> ---
>>>>>>>>>>> mat_u@testsrv.example:~> id
>>>>>>>>>>> uid=6575(mat_u) gid=100(users)
>>>>>>>>>>> groups=16(dialout),33(video),100(users)
>>>>>>>>>>> context=mat_u:staff_r:staff_t
>>>>>>>>>>> mat_u@testsrv.example:~> newrole -r sysadm_r
>>>>>>>>>>> mat_u@testsrv.example:~> id
>>>>>>>>>>> uid=6575(mat_u) gid=100(users)
>>>>>>>>>>> groups=16(dialout),33(video),100(users)
>>>>>>>>>>> context=mat_u:sysadm_r:sysadm_t
>>>>>>>>>>> --------------------
>>>>>>>>>>>
>>>>>>>>>>> So, this is okey. The user's context after login is
>>>>>>>>>>> "mat_u:staff_r:staff_t"
>>>>>>>>>>>
>>>>>>>>>>> But, if the Linux User is different from the SELinux User, the
>>>>>>>>>>> default
>>>>>>>>>>> user's will be chosen instead.
>>>>>>>>>>>
>>>>>>>>>>> Here is the example (SELinux User=mat_u, Linux User=mat):
>>>>>>>>>>> ---------------------
>>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]: Accepted
>>>>>>>>>>> keyboard-interactive/pam for mat from 131.102.233.125 port 54726
>>>>>>>>>>> ssh2
>>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> Open Session
>>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> Open Session
>>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> Username= mat SELinux User = mat_u Level= (null)
>>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> set mat security context to mat_u:staff_r:staff_t
>>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>>> set mat key creation context to mat_u:staff_r:staff_t
>>>>>>>>>>> ---
>>>>>>>>>>> mat_u@testsrv.example:~> id
>>>>>>>>>>> uid=6575(mat) gid=100(users)
>>>>>>>>>>> groups=16(dialout),33(video),100(users)
>>>>>>>>>>> context=user_u:user_r:user_t
>>>>>>>>>>>
>>>>>>>>>>> mat_u@testsrv.example:~> newrole -r sysadm_r
>>>>>>>>>>> user_u:sysadm_r:sysadm_t is not a valid context
>>>>>>>>>>> ---------------------
>>>>>>>>>>>
>>>>>>>>>>> As you can see, the pam_selinux module recognizes that the new
>>>>>>>>>>> context
>>>>>>>>>>> should be "mat_u:staff_r:staff_t", but for some reason the real
>>>>>>>>>>> context
>>>>>>>>>>> is
>>>>>>>>>>> user_u:user_r:user_t. Changing the context with newrole doesn't
>>>>>>>>>>> work
>>>>>>>>>>> either...
>>>>>>>>>>>
>>>>>>>>>>> The user mappings should be okey:
>>>>>>>>>>> ------
>>>>>>>>>>> semanage user -l | grep mat
>>>>>>>>>>> mat_u staff_r sysadm_r
>>>>>>>>>>> testsrv.example:~ # semanage login -l | grep mat
>>>>>>>>>>> mat
>>>>>>>>>>> -------
>>>>>>>>>>>
>>>>>>>>>>> Any idea out there? Do I miss something?
>>>>>>>>>>> kind regards
>>>>>>>>>>> Matthias
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> This message was distributed to subscribers of the selinux mailing
>>>>>>>>>>> list.
>>>>>>>>>>> If you no longer wish to subscribe, send mail to
>>>>>>>>>>> majordomo@tycho.nsa.gov
>>>>>>>>>>> with
>>>>>>>>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> you can specify the context in
>>>>>>>>>> /etc/selinux/policy/contexts/users/whatroleyouused
>>>>>>>>>> (under sshd) I normally set user_r:user_t:s0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Justin P. Mattock
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> This message was distributed to subscribers of the selinux mailing
>>>>>>>>>> list.
>>>>>>>>>> If you no longer wish to subscribe, send mail to
>>>>>>>>>> majordomo@tycho.nsa.gov
>>>>>>>>>> with
>>>>>>>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The file looks like:
>>>>>>>>> cat /etc/selinux/refpolicy/contexts/users/mat_u
>>>>>>>>> system_r:local_login_t staff_r:staff_t sysadm_r:sysadm_t
>>>>>>>>> system_r:remote_login_t staff_r:staff_t
>>>>>>>>> system_r:sshd_t staff_r:staff_t sysadm_r:sysadm_t
>>>>>>>>> system_r:crond_t staff_r:cronjob_t
>>>>>>>>> system_r:xdm_t staff_r:staff_t
>>>>>>>>> staff_r:staff_su_t staff_r:staff_t
>>>>>>>>> staff_r:staff_sudo_t staff_r:staff_t
>>>>>>>>> sysadm_r:sysadm_su_t sysadm_r:sysadm_t
>>>>>>>>> sysadm_r:sysadm_sudo_t sysadm_r:sysadm_t
>>>>>>>>>
>>>>>>>>> So, theoretical this should be okey, isn't it?
>>>>>>>>> And as you can see in the log from above (set mat key creation
>>>>>>>>> context
>>>>>>>>> to
>>>>>>>>> mat_u:staff_r:staff_t) it "tries" to switch to staff but for some
>>>>>>>>> reason
>>>>>>>>> it doesn't work..
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> if your sshd'ing and the context is staff_r:staff_t then it's
>>>>>>>> correct,
>>>>>>>> I
>>>>>>>> usually change this to user_r:user_t just cause I'm paranoid.
>>>>>>>> Also there is some options that you can set in /etc/pam.d to do other
>>>>>>>> checks etc..
>>>>>>>>
>>>>>>>> Justin P. Mattock
>>>>>>>>
>>>>>>> no it's not and that't the problem:)
>>>>>>> If I sshd'ing with mat_u it's always "user_r:user_t" even
>>>>>>> "staff_r:staff_t" is specified (see above). But it's correct if the
>>>>>>> selinux and linux users are named equaly (mat in the example).
>>>>>>> It seems that something with the context settings and usermapping
>>>>>>> isn't
>>>>>>> correct. Do you see the problem?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Somewhere in the policy it is set to default to user_r for sshd, I dont
>>>>>> think there is a boolean(but could be wrong)for that feature. maybe
>>>>>> it's
>>>>>> reading the default_contexts file which is set to use user_r:user_t
>>>>>> instead of reading mat_u for sshd(staff_r:staff_t)
>>>>>>
>>>>>> Justin P. Mattock
>>>>>>
>>>>>>
>>>>> Unfortunately I can't see a rule doing this. The curious thing is, that
>>>>> it
>>>>> works if the selinux user and the linux user are equivalent (both
>>>>> mat_u).
>>>>> But it does NOT work if it is mat (linux user) and mapped to mat_u
>>>>> (selinux user).
>>>>>
>>>>>
>>>>
>>>>
>>>> hmm.. something seems configured wrong, what OS are you using? do you
>>>> have semanage login/user -l set up correctly?
>>>>
>>>> over here I build the policy from git, normally edit policy/users (add)
>>>> gen_user(name,system_u, sysadm_r staff_r user_r, s0, s0 -
>>>> mls_systemhigh, mcs_allcats)
>>>>
>>>> then after the policy is built and installed/loaded I do
>>>> semanage login -a -s name name (create name in contexts/users)
>>>> (or skip the above and just use semanage -a -s user_u name)
>>>>
>>>> seems sshd works with the given context I specify(user_r) then if I want
>>>> to add more options I adjust /etc/pam.d/*
>>>>
>>>> Justin P. Mattock
>>>>
>>> Thanks for your reply.
>>> I'm using SLES 11 SP1. It wouldn't be the first bug regarding SELinux on
>>> this distro... ;)
>>> Here is what I've done so far.
>>> - Downloaded the latest reference policy from tresys
>>> - Compiled and installed it on my sles 11.1
>>> - Add selinux user mat_u: "semanage user -R "staff_r system_r" -P user -a
>>> mat_u"
>>> - Add linux user mat: "useradd mat"
>>> - Set password for mat: "passwd mat"
>>> - User mapping: "semanage login -s mat_u -a mat"
>>> - add security context for mat_u by copying staff_u's context
>>> "cp /etc/selinux/refpolicy/contexts/user/staff_u
>>> /etc/selinux/refpolicy/contexts/user/mat_u"
>>> - set boolean for sysadm ssh login to true: "setsebool -P ssh_sysadm_login
>>> on"
>>>
>>> Do you know good debug options for tracing where it stucks?
>>>
>> When debugging login-type programs figuring out the context to transition
>> to, there are a couple of simple useful utilities in libselinux/utils. These
>> are getconlist and getdefaultcon. Most distros won't install these (as
>> they're just debugging tools), but you can build them yourself out of the
>> tree.
>>
>> getconlist will print out the contexts returned by
>> get_ordered_context_list(), which are all the reachable contexts. This could
>> tell you if the problem is that the context you're trying to transition to
>> is for some reason unreachable.
>>
>> getdefaultcon can tell you (in verbose mode) the default seuser and level
>> returned by getseuserbyname() and the default context returned by
>> get_default_context_with_rolelevel()/get_default_context_with_level(). If
>> the seuser is wrong, then you know something's going wrong in
>> getseuserbyname().
>>
>> I hope that helps.
>>
>> Thanks,
>> Chad Sellers
>>
>>
>> --
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>>
>>
> We ship them in fedora as selinuxconlist and selinuxdefcon
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyt8UkACgkQrlYvE4MpobPw+wCfa8sf3A8+xhnMmdz2z3/vuJOM
> TYsAn1s18NmE9caf5MpCt312RO2Wh/BI
> =N+E/
> -----END PGP SIGNATURE-----
>
o.k. I just loaded up OpenSUSE11.4, and loaded the policy(this is from
git keep in mind, not what suse offers).
after getting everything setup I was able to ssh into the machine with
my iphone, and issue id -Z.. the context I set is user_r:user_t which
the iphone showed(name:user_r:staff_t:s0) so everything is good with
this version.(not sure with 11.1, but I know 11.2 works fine, as well as
11.4).
Justin P. Mattock
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [PATCH v6 04/12] Add memory slot versioning and use it to provide fast guest write interface
From: Gleb Natapov @ 2010-10-07 17:23 UTC (permalink / raw)
To: Avi Kivity
Cc: Gleb Natapov, Marcelo Tosatti, kvm, linux-mm, linux-kernel, mingo,
a.p.zijlstra, tglx, hpa, riel, cl
In-Reply-To: <4CADF365.3080406@redhat.com>
On Thu, Oct 07, 2010 at 06:20:53PM +0200, Avi Kivity wrote:
> On 10/07/2010 06:03 PM, Gleb Natapov wrote:
> >> >
> >> > Isn't SET_USER_MEMORY_REGION so slow that calling it 2^32 times
> >> > isn't really feasible?
> >>
> >> Assuming it takes 1ms, it would take 49 days.
> >>
> >We may fail ioctl when max value is reached. The question is how much slot
> >changes can we expect from real guest during its lifetime.
> >
>
> A normal guest has a 30 Hz timer for reading the vga framebuffer,
> multiple slots. Let's assume 100 Hz frequency, that gives 490 days
> until things stop working.
>
And reading vga framebuffer needs slots changes because of dirty map
tracking?
--
Gleb.
^ permalink raw reply
* Re: [PATCH] ext4: queue conversion after adding to inode's completed IO list
From: Eric Sandeen @ 2010-10-07 17:23 UTC (permalink / raw)
To: ext4 development; +Cc: Jiaying Zhang
In-Reply-To: <4C5C67FD.5070208@redhat.com>
On 08/06/2010 02:52 PM, Eric Sandeen wrote:
> By queuing the io end on the unwritten workqueue before adding it
> to our inode's list of completed IOs, I think we run the risk
> of the work getting completed, and the IO freed, before we try
> to add it to the inode's i_completed_io_list.
>
> It should be safe to add it to the inode's list of completed
> IOs, and -then- queue it for completion, I think.
Ping? would be good to fix this race, this has jiaying's ack too.
> Thanks to Dave Chinner for pointing out the race.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
>
> (At least I think this is right; I haven't actually demonstrated a race...)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 0afc8c1..7f56c48 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3804,14 +3804,14 @@ static void ext4_end_io_dio(struct kiocb *iocb, loff_t offset,
> io_end->flag = EXT4_IO_UNWRITTEN;
> wq = EXT4_SB(io_end->inode->i_sb)->dio_unwritten_wq;
>
> - /* queue the work to convert unwritten extents to written */
> - queue_work(wq, &io_end->work);
> -
> /* Add the io_end to per-inode completed aio dio list*/
> ei = EXT4_I(io_end->inode);
> spin_lock_irqsave(&ei->i_completed_io_lock, flags);
> list_add_tail(&io_end->list, &ei->i_completed_io_list);
> spin_unlock_irqrestore(&ei->i_completed_io_lock, flags);
> +
> + /* queue the work to convert unwritten extents to written */
> + queue_work(wq, &io_end->work);
> iocb->private = NULL;
> out:
> if (is_async)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 04/12] Add memory slot versioning and use it to provide fast guest write interface
From: Gleb Natapov @ 2010-10-07 17:23 UTC (permalink / raw)
To: Avi Kivity
Cc: Gleb Natapov, Marcelo Tosatti, kvm, linux-mm, linux-kernel, mingo,
a.p.zijlstra, tglx, hpa, riel, cl
In-Reply-To: <4CADF365.3080406@redhat.com>
On Thu, Oct 07, 2010 at 06:20:53PM +0200, Avi Kivity wrote:
> On 10/07/2010 06:03 PM, Gleb Natapov wrote:
> >> >
> >> > Isn't SET_USER_MEMORY_REGION so slow that calling it 2^32 times
> >> > isn't really feasible?
> >>
> >> Assuming it takes 1ms, it would take 49 days.
> >>
> >We may fail ioctl when max value is reached. The question is how much slot
> >changes can we expect from real guest during its lifetime.
> >
>
> A normal guest has a 30 Hz timer for reading the vga framebuffer,
> multiple slots. Let's assume 100 Hz frequency, that gives 490 days
> until things stop working.
>
And reading vga framebuffer needs slots changes because of dirty map
tracking?
--
Gleb.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PULL] virtio, vhost fixes
From: Michael S. Tsirkin @ 2010-10-07 17:16 UTC (permalink / raw)
To: avi, mtosatti, kvm
The following patches fix qemu-kvm specific crashes
with vhost-net. They need to be applied before
qemu.git including analogous changes is merged,
otherwise bisect is broken.
They are needed on stable as well.
The following changes since commit c2333d898b52a9d64845522f18fd083534dc0a5b:
kvm: allow tpr patching to write to write-protected vapic option rom (2010-10-05 15:02:34 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git vhost
Michael S. Tsirkin (5):
virtio: invoke set_status callback on reset
virtio-net: unify vhost-net start/stop
vhost: fix up irqfd support
vhost: error code
msix: factor out mask notifier code
hw/msix.c | 82 +++++++++++++++++++++++++++++---------------------
hw/msix.h | 4 +-
hw/pci.h | 3 +-
hw/vhost.c | 54 ++++++++++++++++++---------------
hw/virtio-net.c | 89 ++++++++++++++++++++++++++----------------------------
hw/virtio-pci.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++------
hw/virtio.c | 2 +
hw/virtio.h | 2 +-
8 files changed, 201 insertions(+), 120 deletions(-)
--
MST
^ permalink raw reply
* Re: [PATCH v6 03/12] Retry fault before vmentry
From: Gleb Natapov @ 2010-10-07 17:21 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADBD13.4040609@redhat.com>
On Thu, Oct 07, 2010 at 02:29:07PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >When page is swapped in it is mapped into guest memory only after guest
> >tries to access it again and generate another fault. To save this fault
> >we can map it immediately since we know that guest is going to access
> >the page. Do it only when tdp is enabled for now. Shadow paging case is
> >more complicated. CR[034] and EFER registers should be switched before
> >doing mapping and then switched back.
>
> With non-pv apf, I don't think we can do shadow paging. The guest
Yes, with non-pv this trick will not work without tdp. I haven't even
considered it for that case.
> isn't aware of the apf, so as far as it is concerned it is allowed
> to kill the process and replace it with something else:
>
> guest process x: apf
> kvm: timer intr
> guest kernel: context switch
> very fast guest admin: pkill -9 x
> guest kernel: destroy x's cr3
> guest kernel: reuse x's cr3 for new process y
> kvm: retry fault, instantiating x's page in y's page table
>
> Even with tdp, we have the same case for nnpt (just
> s/kernel/hypervisor/ and s/process/guest/). What we really need is
> to only instantiate the page for direct maps, which are independent
> of the guest.
>
> Could be done like this:
>
> - at apf time, walk shadow mmu
> - if !sp->role.direct, abort
> - take reference to sp
> - on apf completion, instantiate spte in sp
>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
--
Gleb.
^ permalink raw reply
* Re: [PATCH] mac80211: fix sw scan locking
From: Ben Greear @ 2010-10-07 17:22 UTC (permalink / raw)
To: Johannes Berg
Cc: John Linville, linux-wireless@vger.kernel.org, Stanislaw Gruszka
In-Reply-To: <1286448924.3657.35.camel@jlt3.sipsolutions.net>
On 10/07/2010 03:55 AM, Johannes Berg wrote:
> From: Johannes Berg<johannes.berg@intel.com>
>
> The recent scan overhaul broke locking
> because now we can jump to code that
> attempts to unlock, while we don't have
> the mutex held. Fix this by holding the
> mutex around all the relevant code.
>
> Reported-by: Ben Greear<greearb@candelatech.com>
> Signed-off-by: Johannes Berg<johannes.berg@intel.com>
That does indeed fix the problem for me.
Thanks,
Ben
> ---
> net/mac80211/scan.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- wireless-testing.orig/net/mac80211/scan.c 2010-10-07 10:50:51.000000000 +0200
> +++ wireless-testing/net/mac80211/scan.c 2010-10-07 10:51:10.000000000 +0200
> @@ -682,8 +682,6 @@ void ieee80211_scan_work(struct work_str
> goto out_complete;
> }
>
> - mutex_unlock(&local->mtx);
> -
> /*
> * as long as no delay is required advance immediately
> * without scheduling a new work
> @@ -714,6 +712,7 @@ void ieee80211_scan_work(struct work_str
> } while (next_delay == 0);
>
> ieee80211_queue_delayed_work(&local->hw,&local->scan_work, next_delay);
> + mutex_unlock(&local->mtx);
> return;
>
> out_complete:
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] mac80211: Deny new BA agreements from being started during offchannel operation
From: Luis R. Rodriguez @ 2010-10-07 17:21 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, John W. Linville, Srinivasa Duvvuri, Matt Smith,
Bennyam Malavazi, linux-wireless@vger.kernel.org
In-Reply-To: <1286435892.3657.9.camel@jlt3.sipsolutions.net>
On Thu, Oct 7, 2010 at 12:18 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2010-10-06 at 13:48 -0700, Luis R. Rodriguez wrote:
>> On Wed, Oct 6, 2010 at 12:19 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>> > On Wed, 2010-10-06 at 12:12 -0700, Luis R. Rodriguez wrote:
>> >
>> >> Good question, will ieee80211_offchannel_ps_disable() possibly be
>> >> called during suspend? I can imagine its possible. So how about we
>> >> check for local->quiescing prior to lifting the flag only:
>> >
>> > Or suspended?
>>
>> If we're suspended we would be quiesced so I do not see us calling
>> ieee80211_offchannel_ps_disable() then, but we can also just bail out
>> if quescing or suspended on ieee80211_offchannel_ps_disable() and
>> friends.
>
> Oh, wait, yeah, while quiescing we stop the workqueue so we can't be
> processing this, so we should be fine.
Right.
> We might still be off-channel
> while suspending which is odd, and then we might lift the BA block
> earlier than you'd want.
Hehe.. unless we deny going off channel when quiescing or suspended.
> But then again, come to think of it, why are you doing this anyway?
The goal is to clean up a lot of stuff we forgot to cleanup for
offchannel operation and in the end to help with multicast/broadcast
data. This patch just addresses one of the cleanups. The timers kicked
off when going off channel will not make sense, so best to just deny
ADDBA when going offchannel.
> I'm not convinced of the whole idea, it's all racy. I'm starting to think
> that this patch won't help anything since we'll still be racy and start
> BA agreements just before we block,
Establishing the BA agreement is fine, we don't want to cancel
existing BA agreements when going offchannel, we just want to prevent
making the timers for new ADDBA requests from going stale
unnecessarily.
> _and_ if we're a station and going off-channel we'll be going into powersave
> which means we won't actually get the addBA frame until we return.
There's a race between trying to go offchannel, sending the nullfunc
and switching channels. When the race hits the ADDBA timer will just
go stale. If our goal is to go offchannel we should avoid the race by
simply denying new ADDBA requests. I just noticed that we can't
possible receive ADDBA requests when we are scanning though, since
ieee80211_iface_work() already has a check and bail out for
local->scanning, but note that local->scanning will not be checked
when doing other offchannel work.
So perhaps there is another way we can deal with this for the
non-scanning offchannel work case that might also take care of not
handling other queued up management frames when offchannel.
Luis
^ permalink raw reply
* Re: [PATCH v6 03/12] Retry fault before vmentry
From: Gleb Natapov @ 2010-10-07 17:21 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADBD13.4040609@redhat.com>
On Thu, Oct 07, 2010 at 02:29:07PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >When page is swapped in it is mapped into guest memory only after guest
> >tries to access it again and generate another fault. To save this fault
> >we can map it immediately since we know that guest is going to access
> >the page. Do it only when tdp is enabled for now. Shadow paging case is
> >more complicated. CR[034] and EFER registers should be switched before
> >doing mapping and then switched back.
>
> With non-pv apf, I don't think we can do shadow paging. The guest
Yes, with non-pv this trick will not work without tdp. I haven't even
considered it for that case.
> isn't aware of the apf, so as far as it is concerned it is allowed
> to kill the process and replace it with something else:
>
> guest process x: apf
> kvm: timer intr
> guest kernel: context switch
> very fast guest admin: pkill -9 x
> guest kernel: destroy x's cr3
> guest kernel: reuse x's cr3 for new process y
> kvm: retry fault, instantiating x's page in y's page table
>
> Even with tdp, we have the same case for nnpt (just
> s/kernel/hypervisor/ and s/process/guest/). What we really need is
> to only instantiate the page for direct maps, which are independent
> of the guest.
>
> Could be done like this:
>
> - at apf time, walk shadow mmu
> - if !sp->role.direct, abort
> - take reference to sp
> - on apf completion, instantiate spte in sp
>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
--
Gleb.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
From: Kevin Hilman @ 2010-10-07 17:20 UTC (permalink / raw)
To: Ben Dooks
Cc: Jon Povey, davinci-linux-open-source@linux.davincidsp.com,
linux-i2c@vger.kernel.org
In-Reply-To: <87wrpu9bsu.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org> writes:
> Jon Povey <Jon.Povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org> writes:
>
>> Hi Ben,
>>
>> I am not on the i2c list but noticed this pull request:
>> http://www.spinics.net/linux/lists/linux-i2c/msg04022.html
>>
>> I think you have the wrong (old) version of this patch in that branch,
>> http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0
>>
>> The correct v4 one from the start of this thread has more lines
>> of patch and this commit message:
>
> It is also available in my davinci-i2c branch:
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c
>
> Thanks Jon for catching this,
I just noticed that it has already been pulled and is part of -rc7.
Jon, care to submit a new patch with v4 diff and including the acks and
tested-bys?
Thanks,
Kevin
^ permalink raw reply
* Re: [PULL] Pull request from msysGit
From: Ramsay Jones @ 2010-10-07 17:17 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Junio C Hamano, git, msysgit, pharris, sschuberth
In-Reply-To: <87ocb9zfbf.fsf@fox.patthoyts.tk>
Pat Thoyts wrote:
> The following changes since commit 1e633418479926bc85ed21a4f91c845a3dd3ad66:
>
> Merge branch 'maint' (2010-09-30 14:59:53 -0700)
>
> are available in the git repository at:
>
> git://repo.or.cz/git/mingw/4msysgit.git work/pt/for-junio
> or alternatively
> http://repo.or.cz/w/git/mingw/4msysgit.git/shortlog/refs/heads/work/pt/for-junio
>
> 5debf9a Add MinGW-specific execv() override.
> 77df1f1 Fix Windows-specific macro redefinition warning.
> b248e95 Fix 'clone' failure at DOS root directory.
> 1a40420 mingw: do not crash on open(NULL, ...)
> 5e9677c git-am: fix detection of absolute paths for windows
> 36e035f Side-step MSYS-specific path "corruption" leading to t5560 failure.
> ca02ad3 Side-step sed line-ending "corruption" leading to t6038 failure.
> 97f2c33 Skip 'git archive --remote' test on msysGit
> a94114a Do not strip CR when grepping HTTP headers.
> 3ba9ba8 Skip t1300.70 and 71 on msysGit.
> 4e57baf merge-octopus: Work around environment issue on Windows
> 442dada MinGW: Report errors when failing to launch the html browser.
> 9b9784c MinGW: fix stat() and lstat() implementations for handling symlinks
> 4091bfc MinGW: Add missing file mode bit defines
This commit (4091bfc) may well introduce logic errors into the msvc
build; I haven't checked (it depends on what the msvc compiler does
when a macro is redefined - does the new definition replace the old?).
However, no matter what else may be wrong, this commit introduces a
shed load of new warnings, thus:
$ make clean
$ make MSVC=1 >out 2>&1
$ grep warning out | grep S_I | wc -l
1000
$
so 1000 additional warnings which, looking at the start of the out
file, look like this:
GIT_VERSION = 1.7.3.dirty
* new build flags or prefix
CC fast-import.o
fast-import.c
c:\cygwin\home\ramsay\git\compat/mingw.h(16) : warning C4005: 'S_IRUSR' : macro redefinition
compat/vcbuild/include\unistd.h(85) : see previous definition of 'S_IRUSR'
c:\cygwin\home\ramsay\git\compat/mingw.h(17) : warning C4005: 'S_IWUSR' : macro redefinition
compat/vcbuild/include\unistd.h(84) : see previous definition of 'S_IWUSR'
c:\cygwin\home\ramsay\git\compat/mingw.h(18) : warning C4005: 'S_IXUSR' : macro redefinition
compat/vcbuild/include\unistd.h(83) : see previous definition of 'S_IXUSR'
c:\cygwin\home\ramsay\git\compat/mingw.h(19) : warning C4005: 'S_IRWXU' : macro redefinition
compat/vcbuild/include\unistd.h(82) : see previous definition of 'S_IRWXU'
Now, Peter Harris has already submitted a fix for this, which is
currently on the work/msvc-fixes branch, which contains:
358f1be Modify MSVC wrapper script
38bd27d Fix MSVC build
The suggested fix is given in commit 38bd27d. However, I prefer a
different solution, which is given below:
--- >8 ---
diff --git a/compat/mingw.h b/compat/mingw.h
index afedf3a..445d1a1 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -12,12 +12,6 @@ typedef int pid_t;
#define S_ISLNK(x) (((x) & S_IFMT) == S_IFLNK)
#define S_ISSOCK(x) 0
-#ifndef _STAT_H_
-#define S_IRUSR 0
-#define S_IWUSR 0
-#define S_IXUSR 0
-#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
-#endif
#define S_IRGRP 0
#define S_IWGRP 0
#define S_IXGRP 0
--- 8< ---
Note that, for *both* MinGW and MSVC, the deleted #defines
are not wanted, pointless and just plain wrong! :-D
If you squash the above into 4091bfc then we find:
$ make clean
$ make MSVC=1 >out1 2>&1
$ grep warning out1 | grep S_I | wc -l
0
$
and there is also no chance of introducing a logic error.
Although I'm not recommending you use one of the commits on
the work/msvc-fixes branch, can I request, once again, that
you include:
358f1be Modify MSVC wrapper script
If it makes any difference, you can add:
Acked-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
ATB,
Ramsay Jones
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/fsl_booke: Add support to boot from core other than 0
From: Kumar Gala @ 2010-10-07 17:19 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1283297085-3455-2-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 6:24 PM, Matthew McClintock wrote:
> First we check to see if we are the first core booting up. This
> is accomplished by comparing the boot_cpuid with -1, if it is we
> assume this is the first core coming up.
>
> Secondly, we need to update the initial thread info structure
> to reflect the actual cpu we are running on otherwise
> smp_processor_id() and related functions will return the default
> initialization value of the struct or 0.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
> arch/powerpc/kernel/setup_32.c | 2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH v6 08/12] Handle async PF in a guest.
From: Avi Kivity @ 2010-10-07 17:18 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <20101007171418.GA2397@redhat.com>
On 10/07/2010 07:14 PM, Gleb Natapov wrote:
> On Thu, Oct 07, 2010 at 03:10:27PM +0200, Avi Kivity wrote:
> > On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> > >When async PF capability is detected hook up special page fault handler
> > >that will handle async page fault events and bypass other page faults to
> > >regular page fault handler. Also add async PF handling to nested SVM
> > >emulation. Async PF always generates exit to L1 where vcpu thread will
> > >be scheduled out until page is available.
> > >
> >
> > Please separate guest and host changes.
> >
> > >+void kvm_async_pf_task_wait(u32 token)
> > >+{
> > >+ u32 key = hash_32(token, KVM_TASK_SLEEP_HASHBITS);
> > >+ struct kvm_task_sleep_head *b =&async_pf_sleepers[key];
> > >+ struct kvm_task_sleep_node n, *e;
> > >+ DEFINE_WAIT(wait);
> > >+
> > >+ spin_lock(&b->lock);
> > >+ e = _find_apf_task(b, token);
> > >+ if (e) {
> > >+ /* dummy entry exist -> wake up was delivered ahead of PF */
> > >+ hlist_del(&e->link);
> > >+ kfree(e);
> > >+ spin_unlock(&b->lock);
> > >+ return;
> > >+ }
> > >+
> > >+ n.token = token;
> > >+ n.cpu = smp_processor_id();
> > >+ init_waitqueue_head(&n.wq);
> > >+ hlist_add_head(&n.link,&b->list);
> > >+ spin_unlock(&b->lock);
> > >+
> > >+ for (;;) {
> > >+ prepare_to_wait(&n.wq,&wait, TASK_UNINTERRUPTIBLE);
> > >+ if (hlist_unhashed(&n.link))
> > >+ break;
> > >+ local_irq_enable();
> >
> > Suppose we take another apf here. And another, and another (for
> > different pages, while executing schedule()). What's to prevent
> > kernel stack overflow?
> >
> Host side keeps track of outstanding apfs and will not send apf for the
> same phys address twice. It will halt vcpu instead.
What about different pages, running the scheduler code?
Oh, and we'll run the scheduler recursively.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v6 08/12] Handle async PF in a guest.
From: Avi Kivity @ 2010-10-07 17:18 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <20101007171418.GA2397@redhat.com>
On 10/07/2010 07:14 PM, Gleb Natapov wrote:
> On Thu, Oct 07, 2010 at 03:10:27PM +0200, Avi Kivity wrote:
> > On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> > >When async PF capability is detected hook up special page fault handler
> > >that will handle async page fault events and bypass other page faults to
> > >regular page fault handler. Also add async PF handling to nested SVM
> > >emulation. Async PF always generates exit to L1 where vcpu thread will
> > >be scheduled out until page is available.
> > >
> >
> > Please separate guest and host changes.
> >
> > >+void kvm_async_pf_task_wait(u32 token)
> > >+{
> > >+ u32 key = hash_32(token, KVM_TASK_SLEEP_HASHBITS);
> > >+ struct kvm_task_sleep_head *b =&async_pf_sleepers[key];
> > >+ struct kvm_task_sleep_node n, *e;
> > >+ DEFINE_WAIT(wait);
> > >+
> > >+ spin_lock(&b->lock);
> > >+ e = _find_apf_task(b, token);
> > >+ if (e) {
> > >+ /* dummy entry exist -> wake up was delivered ahead of PF */
> > >+ hlist_del(&e->link);
> > >+ kfree(e);
> > >+ spin_unlock(&b->lock);
> > >+ return;
> > >+ }
> > >+
> > >+ n.token = token;
> > >+ n.cpu = smp_processor_id();
> > >+ init_waitqueue_head(&n.wq);
> > >+ hlist_add_head(&n.link,&b->list);
> > >+ spin_unlock(&b->lock);
> > >+
> > >+ for (;;) {
> > >+ prepare_to_wait(&n.wq,&wait, TASK_UNINTERRUPTIBLE);
> > >+ if (hlist_unhashed(&n.link))
> > >+ break;
> > >+ local_irq_enable();
> >
> > Suppose we take another apf here. And another, and another (for
> > different pages, while executing schedule()). What's to prevent
> > kernel stack overflow?
> >
> Host side keeps track of outstanding apfs and will not send apf for the
> same phys address twice. It will halt vcpu instead.
What about different pages, running the scheduler code?
Oh, and we'll run the scheduler recursively.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: SRP submaintainership
From: Bart Van Assche @ 2010-10-07 17:17 UTC (permalink / raw)
To: Roland Dreier, David Dillow; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <adatyky3pvj.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On Thu, Oct 7, 2010 at 6:54 PM, Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> Dave Dillow has been involved with both kernel development and SRP for
> a long time, and I trust Dave's technical judgement and good taste
> about the SRP code. Dave has graciously agreed to serve as a
> submaintainer for the SRP initiator, which should mean that SRP
> patches will get more focus and also free me to spend more time on
> other maintenance/patch review.
I'd like to congratulate Dave with this new responsibility. It's good
to see the number of linux-RDMA maintainers growing.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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.