twitter: linux.kernel - 20 new messages in 13 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Don't change direction flags in struct request. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e51f804bdda47203?hl=en
* Oops while booting 2.6.34-rc0 (block pull busted) - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f7420e106a3c28db?hl=en
* please pull infiniband.git - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d9f49d52282a9f5f?hl=en
* [PATCH 0/2] Correct behavior for listxattr and 'trusted' xattrs - 4 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/5b44e2eb8c050e04?hl=en
* memcg: dirty pages instrumentation - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
* use of setjmp/longjmp in x86 emulator. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7b2acc7ec923cec7?hl=en
* drivers: net: optimize hex2bin() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/766d35ce753992f1?hl=en
* mm: use the same log level for show_mem() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/42909485541f85ca?hl=en
* ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first
setup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7603bbf89a910ed1?hl=en
* timekeeping: Prevent oops when GENERIC_TIME=n - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a95e45bddc0a0b9e?hl=en
* BNX2: Kernel crashes with 2.6.31 and 2.6.31.9 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c0235d6a433f1e2b?hl=en
* unable to handle kernel paging request on resume with 2.6.33-00001-gbaac35c -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f6bf94c5aedebc4a?hl=en
* x86: apic: Fix mismerge, add arch_probe_nr_irqs() again - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/8d79051b75e0b2aa?hl=en

==============================================================================
TOPIC: Don't change direction flags in struct request.
http://groups.google.com/group/linux.kernel/t/e51f804bdda47203?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:00 am
From: Mike Christie

On 03/01/2010 11:26 PM, James Bottomley wrote:
> On Thu, 2010-03-18 at 22:31 -0700, Hugh Daschbach wrote:
>> The EMC multipath device handler should not change the I/O direction
>> flags of its trespass command request.
>>
>> The CFQ elevator may BUG if the direction flags on an I/O request are
>> changed after allocation. cfq_set_request() and cfq_put_request()
>> count READ and WRITE requests separately. Changing the I/O request
>> direction after blk_get_request() allocates the request throws off
>> this CFQ accounting.
>
> This description doesn't really match what the problem seems to be
> below:
>
>> Signed-off-by: Hugh Daschbach<hdasch@broadcom.com>
>> ---
>> drivers/scsi/device_handler/scsi_dh_emc.c | 8 ++++----
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/scsi/device_handler/scsi_dh_emc.c b/drivers/scsi/device_handler/scsi_dh_emc.c
>> index 6196675..3709342 100644
>> --- a/drivers/scsi/device_handler/scsi_dh_emc.c
>> +++ b/drivers/scsi/device_handler/scsi_dh_emc.c
>> @@ -269,10 +269,12 @@ static struct request *get_req(struct scsi_device *sdev, int cmd,
>> unsigned char *buffer)
>> {
>> struct request *rq;
>> + int mode = READ;
>> int len = 0;
>>
>> - rq = blk_get_request(sdev->request_queue,
>> - (cmd == MODE_SELECT) ? WRITE : READ, GFP_NOIO);
>> + if (cmd == MODE_SELECT || cmd == MODE_SELECT_10)
>> + mode = WRITE;
>> + rq = blk_get_request(sdev->request_queue, mode, GFP_NOIO);
>
> So the actual bug is failure to set WRITE for MODE_SELECT_10.
>

I think we have a fix for this and some len issues in that module that
was sent here:
http://marc.info/?l=linux-scsi&m=125978574800618&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Oops while booting 2.6.34-rc0 (block pull busted)
http://groups.google.com/group/linux.kernel/t/f7420e106a3c28db?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 12:00 am
From: Jens Axboe

On Mon, Mar 01 2010, Dmitry Torokhov wrote:
> Hi,
>
> It looks like block tree that has been pulled today into mainline is
> busted, I am getting the Opps below on boot with the following commit:
>
> commit b1bf9368407ae7e89d8a005bb40beb70a41df539
> Merge: 524df55 4671a13
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon Mar 1 09:00:29 2010 -0800
>
> Merge branch 'for-2.6.34' of git://git.kernel.dk/linux-2.6-block
>
>
> but not with the previous one:
>
> commit 524df55725217b13d5a232fb5badb5846418ea0e
> Merge: 0f45339 6679ee1
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon Mar 1 08:58:44 2010 -0800
>
> Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
>
> This is on plain Fedora 12 VM.
>
> Thanks.
>
> --
> Dmitry
>
> sd 2:0:0:0: Attached scsi generic sg1 type 0
> sd 2:0:0:0: [sda] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
> sd 2:0:0:0: [sda] Write Protect is off
> sd 2:0:0:0: [sda] Cache data unavailable
> sd 2:0:0:0: [sda] Assuming drive cache: write through
> sd 2:0:0:0: [sda] Cache data unavailable
> sd 2:0:0:0: [sda] Assuming drive cache: write through
> sda: sda1 sda2
> sd 2:0:0:0: [sda] Cache data unavailable
> sd 2:0:0:0: [sda] Assuming drive cache: write through
> sd 2:0:0:0: [sda] Attached SCSI disk
> device-mapper: multipath: version 1.1.1 loaded
> dracut: Scanning devices sda2 for LVM volume groups
> dracut: Reading all physical volumes. This may take a while...
> dracut: Found volume group "VolGroup" using metadata type lvm2
> dracut: 2 logical volume(s) in volume group "VolGroup" now active
> EXT4-fs (dm-0): mounted filesystem with ordered data mode
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f
> PGD 3b776067 PUD 3b7b1067 PMD 0
> Oops: 0002 [#1] SMP
> last sysfs file: /sys/kernel/uevent_seqnum
> CPU 0
> Modules linked in: dm_multipath mptspi mptscsih mptbase scsi_transport_spi floppy [last unloaded: scsi_wait_scan]
>
> Pid: 1, comm: init Not tainted 2.6.33 #4 440BX Desktop Reference Platform/VMware Virtual Platform
> RIP: 0010:[<ffffffff81128ee1>] [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f

Can you check where that is? Just do a gdb vmlinux and then an
l *mpage_end_io_read+0x45

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Mar 2 2010 12:20 am
From: Jens Axboe

On Tue, Mar 02 2010, Jens Axboe wrote:
> On Mon, Mar 01 2010, Dmitry Torokhov wrote:
> > Hi,
> >
> > It looks like block tree that has been pulled today into mainline is
> > busted, I am getting the Opps below on boot with the following commit:
> >
> > commit b1bf9368407ae7e89d8a005bb40beb70a41df539
> > Merge: 524df55 4671a13
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date: Mon Mar 1 09:00:29 2010 -0800
> >
> > Merge branch 'for-2.6.34' of git://git.kernel.dk/linux-2.6-block
> >
> >
> > but not with the previous one:
> >
> > commit 524df55725217b13d5a232fb5badb5846418ea0e
> > Merge: 0f45339 6679ee1
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date: Mon Mar 1 08:58:44 2010 -0800
> >
> > Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
> >
> > This is on plain Fedora 12 VM.
> >
> > Thanks.
> >
> > --
> > Dmitry
> >
> > sd 2:0:0:0: Attached scsi generic sg1 type 0
> > sd 2:0:0:0: [sda] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
> > sd 2:0:0:0: [sda] Write Protect is off
> > sd 2:0:0:0: [sda] Cache data unavailable
> > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > sd 2:0:0:0: [sda] Cache data unavailable
> > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > sda: sda1 sda2
> > sd 2:0:0:0: [sda] Cache data unavailable
> > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > sd 2:0:0:0: [sda] Attached SCSI disk
> > device-mapper: multipath: version 1.1.1 loaded
> > dracut: Scanning devices sda2 for LVM volume groups
> > dracut: Reading all physical volumes. This may take a while...
> > dracut: Found volume group "VolGroup" using metadata type lvm2
> > dracut: 2 logical volume(s) in volume group "VolGroup" now active
> > EXT4-fs (dm-0): mounted filesystem with ordered data mode
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> > IP: [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f
> > PGD 3b776067 PUD 3b7b1067 PMD 0
> > Oops: 0002 [#1] SMP
> > last sysfs file: /sys/kernel/uevent_seqnum
> > CPU 0
> > Modules linked in: dm_multipath mptspi mptscsih mptbase scsi_transport_spi floppy [last unloaded: scsi_wait_scan]
> >
> > Pid: 1, comm: init Not tainted 2.6.33 #4 440BX Desktop Reference Platform/VMware Virtual Platform
> > RIP: 0010:[<ffffffff81128ee1>] [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f
>
> Can you check where that is? Just do a gdb vmlinux and then an
> l *mpage_end_io_read+0x45

I tried checking mine here, but we must be using vastly different gcc
versions. So I'd like that output. Can you also try and see if reverting
9f7cdbc33f36d28e57eaba0093f68f0d14c38c5b makes it work?

--
Jens Axboe

== 3 of 3 ==
Date: Tues, Mar 2 2010 12:40 am
From: Jens Axboe

On Tue, Mar 02 2010, Jens Axboe wrote:
> On Tue, Mar 02 2010, Jens Axboe wrote:
> > On Mon, Mar 01 2010, Dmitry Torokhov wrote:
> > > Hi,
> > >
> > > It looks like block tree that has been pulled today into mainline is
> > > busted, I am getting the Opps below on boot with the following commit:
> > >
> > > commit b1bf9368407ae7e89d8a005bb40beb70a41df539
> > > Merge: 524df55 4671a13
> > > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > > Date: Mon Mar 1 09:00:29 2010 -0800
> > >
> > > Merge branch 'for-2.6.34' of git://git.kernel.dk/linux-2.6-block
> > >
> > >
> > > but not with the previous one:
> > >
> > > commit 524df55725217b13d5a232fb5badb5846418ea0e
> > > Merge: 0f45339 6679ee1
> > > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > > Date: Mon Mar 1 08:58:44 2010 -0800
> > >
> > > Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
> > >
> > > This is on plain Fedora 12 VM.
> > >
> > > Thanks.
> > >
> > > --
> > > Dmitry
> > >
> > > sd 2:0:0:0: Attached scsi generic sg1 type 0
> > > sd 2:0:0:0: [sda] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
> > > sd 2:0:0:0: [sda] Write Protect is off
> > > sd 2:0:0:0: [sda] Cache data unavailable
> > > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > > sd 2:0:0:0: [sda] Cache data unavailable
> > > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > > sda: sda1 sda2
> > > sd 2:0:0:0: [sda] Cache data unavailable
> > > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > > sd 2:0:0:0: [sda] Attached SCSI disk
> > > device-mapper: multipath: version 1.1.1 loaded
> > > dracut: Scanning devices sda2 for LVM volume groups
> > > dracut: Reading all physical volumes. This may take a while...
> > > dracut: Found volume group "VolGroup" using metadata type lvm2
> > > dracut: 2 logical volume(s) in volume group "VolGroup" now active
> > > EXT4-fs (dm-0): mounted filesystem with ordered data mode
> > > BUG: unable to handle kernel NULL pointer dereference at (null)
> > > IP: [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f
> > > PGD 3b776067 PUD 3b7b1067 PMD 0
> > > Oops: 0002 [#1] SMP
> > > last sysfs file: /sys/kernel/uevent_seqnum
> > > CPU 0
> > > Modules linked in: dm_multipath mptspi mptscsih mptbase scsi_transport_spi floppy [last unloaded: scsi_wait_scan]
> > >
> > > Pid: 1, comm: init Not tainted 2.6.33 #4 440BX Desktop Reference Platform/VMware Virtual Platform
> > > RIP: 0010:[<ffffffff81128ee1>] [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f
> >
> > Can you check where that is? Just do a gdb vmlinux and then an
> > l *mpage_end_io_read+0x45
>
> I tried checking mine here, but we must be using vastly different gcc
> versions. So I'd like that output. Can you also try and see if reverting
> 9f7cdbc33f36d28e57eaba0093f68f0d14c38c5b makes it work?

OK, so disasm of that reveals that

12: 3e 80 0f 08 orb $0x8,%ds:(%rdi)

is the start of the faulting instruction. You are running UP. 0x8 is the
4th bit, so I'd be surprised if that isn't SetPageUptodate(page).

--
Jens Axboe

==============================================================================
TOPIC: please pull infiniband.git
http://groups.google.com/group/linux.kernel/t/d9f49d52282a9f5f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:00 am
From: Roland Dreier

Linus, please pull from

master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This tree is also available from kernel.org mirrors at:

git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This will get my current pile for the 2.6.34 merge window:

Alexander Chiang (18):
IB/uverbs: Convert *cdev to cdev in struct ib_uverbs_device
IB/uverbs: Remove dev_table
IB/uverbs: Use stack variable 'devnum' in ib_uverbs_add_one
IB/uverbs: use stack variable 'base' in ib_uverbs_add_one
IB/uverbs: Increase maximum devices supported
IB/uverbs: Pack struct ib_uverbs_event_file tighter
IB/uverbs: Whitespace cleanup
IB/umad: Convert *cdev to cdev in struct ib_umad_port
IB/umad: Remove port_table[]
IB/umad: Use stack variable 'devnum' in ib_umad_init_port
IB/umad: Use stack variable 'base' in ib_umad_init_port
IB/umad: Increase maximum devices supported
IB/umad: Clean whitespace
IB/ucm: Use stack variable 'devnum' in ib_ucm_add_one
IB/ucm: Use stack variable 'base' in ib_ucm_add_one
IB/ucm: Increase maximum devices supported
IB/ucm: Clean whitespace errors
IB/core: Pack struct ib_device a little tighter

Alexander Schmidt (3):
IB/ehca: Do not turn off irqs in tasklet context
IB/ehca: Allow access for ib_query_qp()
IB/ehca: Require in_wc in process_mad()

Bart Van Assche (1):
IB/srp: Split send and recieve CQs to reduce number of interrupts

Chien Tung (1):
RDMA/nes: Add support for KR device id 0x0110

Eli Cohen (2):
IB/mlx4: Simplify retrieval of ib_device
IB/core: Fix and clean up ib_ud_header_init()

Faisal Latif (3):
RDMA/nes: Use atomic counters for CM listener create and destroy
RDMA/nes: Fix crash when listener destroyed during loopback setup
RDMA/nes: Multiple disconnects cause crash during AE handling

Jiri Slaby (1):
RDMA: Use rlimit helpers

Or Gerlitz (11):
IPoIB: Remove TX moderation settings from ethtool support
RDMA/nes: Change WQ overflow return code
IB/iser: Revert commit bba7ebb "avoid recv buffer exhaustion"
IB/iser: New receive buffer posting logic
IB/iser: Remove atomic counter for posted receive buffers
IB/iser: Use different CQ for send completions
IB/iser: Simplify send flow/descriptors
IB/iser: Use atomic allocations
IB/iser: Remove unnecessary connection checks
IB/iser: Use libiscsi passthrough mode
IB/iser: Remove redundant locking from iser scsi command response flow

Roland Dreier (11):
IB/uverbs: Use anon_inodes instead of private infinibandeventfs
IB/srp: Clean up error path in srp_create_target_ib()
Merge branch 'cma' into for-next
Merge branch 'cxgb3' into for-next
Merge branch 'ehca' into for-next
Merge branch 'ipoib' into for-next
Merge branch 'iser' into for-next
Merge branch 'mlx4' into for-next
Merge branch 'nes' into for-next
Merge branch 'srp' into for-next
Merge branch 'misc' into for-next

Sean Hefty (1):
RDMA/cm: Remove unused definition of RDMA_PS_SCTP

Steve Wise (5):
RDMA/cxgb3: Remove BUG_ON() on CQ rearm failure
RDMA/cxgb3: Doorbell overflow avoidance and recovery
RDMA/cxgb3: Increase the max CQ depth
RDMA/cxgb3: Don't allocate the SW queue for user mode CQs
RDMA/cxgb3: Mark RDMA device with CXIO_ERROR_FATAL when removing

drivers/infiniband/Kconfig | 1 +
drivers/infiniband/core/ucm.c | 63 +++-
drivers/infiniband/core/ud_header.c | 14 +-
drivers/infiniband/core/umem.c | 2 +-
drivers/infiniband/core/user_mad.c | 173 +++++----
drivers/infiniband/core/uverbs.h | 11 +-
drivers/infiniband/core/uverbs_main.c | 234 +++++------
drivers/infiniband/hw/cxgb3/cxio_hal.c | 15 +-
drivers/infiniband/hw/cxgb3/cxio_hal.h | 4 +-
drivers/infiniband/hw/cxgb3/cxio_wr.h | 17 +-
drivers/infiniband/hw/cxgb3/iwch.c | 80 ++++-
drivers/infiniband/hw/cxgb3/iwch.h | 2 +
drivers/infiniband/hw/cxgb3/iwch_provider.c | 2 +-
drivers/infiniband/hw/cxgb3/iwch_qp.c | 9 +-
drivers/infiniband/hw/ehca/ehca_irq.c | 5 +-
drivers/infiniband/hw/ehca/ehca_qp.c | 4 +-
drivers/infiniband/hw/ehca/ehca_sqp.c | 2 +-
drivers/infiniband/hw/ipath/ipath_user_pages.c | 3 +-
drivers/infiniband/hw/mlx4/qp.c | 4 +-
drivers/infiniband/hw/mthca/mthca_qp.c | 2 +-
drivers/infiniband/hw/nes/nes.c | 1 +
drivers/infiniband/hw/nes/nes.h | 9 +-
drivers/infiniband/hw/nes/nes_cm.c | 11 +-
drivers/infiniband/hw/nes/nes_hw.c | 488 ++++++++++++-----------
drivers/infiniband/hw/nes/nes_hw.h | 2 +-
drivers/infiniband/hw/nes/nes_nic.c | 61 +---
drivers/infiniband/hw/nes/nes_verbs.c | 6 +-
drivers/infiniband/ulp/ipoib/ipoib_ethtool.c | 10 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 47 ++-
drivers/infiniband/ulp/iser/iscsi_iser.h | 97 +++---
drivers/infiniband/ulp/iser/iser_initiator.c | 506 ++++++++----------------
drivers/infiniband/ulp/iser/iser_memory.c | 64 +---
drivers/infiniband/ulp/iser/iser_verbs.c | 281 +++++++-------
drivers/infiniband/ulp/srp/ib_srp.c | 91 +++--
drivers/infiniband/ulp/srp/ib_srp.h | 6 +-
drivers/net/cxgb3/adapter.h | 5 +
drivers/net/cxgb3/cxgb3_main.c | 57 +++-
drivers/net/cxgb3/cxgb3_offload.h | 5 +-
drivers/net/cxgb3/regs.h | 16 +
drivers/net/cxgb3/sge.c | 10 +-
drivers/net/cxgb3/t3_hw.c | 5 +-
include/rdma/ib_pack.h | 1 +
include/rdma/ib_verbs.h | 4 +-
include/rdma/rdma_cm.h | 1 -
44 files changed, 1221 insertions(+), 1210 deletions(-)
--
Roland Dreier <rolandd@cisco.com>
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [PATCH 0/2] Correct behavior for listxattr and 'trusted' xattrs
http://groups.google.com/group/linux.kernel/t/5b44e2eb8c050e04?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Mar 2 2010 12:10 am
From: James Morris

I noticed that there are differences in the behavior of listxattr(2) for
xattrs in the trusted namespace.

Some filesystems, such as ext[234], require CAP_SYS_ADMIN for this, i.e.
trusted xattr names are hidden from unprivileged users.

I audited the kernel for users of the trusted xattr namespace, and found
the following filesystems not checking for CAP_SYS_ADMIN:

- jffs2
- ocfs2
- btrfs
- xfs

I've created patches for jffs2 (tested) and ocfs2 (not tested) to add the
check -- see following emails. btrfs and xfs have custom listxattr
operations and will need a bit more work to fix.

I'm not sure what the initial intention was for the behavior, although
given that several major filesystems are have been fielded with the
CAP_SYS_ADMIN check, it seems most prudent to make this the standard
behavior for all filesystems, in case any users are depending on it.

Thoughts?

- James
--
James Morris
<jmorris@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Tues, Mar 2 2010 12:10 am
From: James Morris

Ensure that trusted xattrs are not returned to unprivileged users
via listxattr, in keeping with several other implmentations, such
as ext3.

Signed-off-by: James Morris <jmorris@namei.org>
---
fs/ocfs2/xattr.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 8fc6fb0..da98448 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -7077,6 +7077,9 @@ static size_t ocfs2_xattr_trusted_list(struct dentry *dentry, char *list,
const size_t prefix_len = XATTR_TRUSTED_PREFIX_LEN;
const size_t total_len = prefix_len + name_len + 1;

+ if (!capable(CAP_SYS_ADMIN))
+ return 0;
+
if (list && total_len <= list_size) {
memcpy(list, XATTR_TRUSTED_PREFIX, prefix_len);
memcpy(list + prefix_len, name, name_len);
--
1.6.3.3

== 3 of 4 ==
Date: Tues, Mar 2 2010 12:10 am
From: James Morris

Ensure that trusted xattrs are not returned to unprivileged users
via listxattr, in keeping with several other implmentations, such
as ext3.

Signed-off-by: James Morris <jmorris@namei.org>
---
fs/jffs2/xattr_trusted.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 3e5a5e3..405121c 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -39,6 +39,9 @@ static size_t jffs2_trusted_listxattr(struct dentry *dentry, char *list,
{
size_t retlen = XATTR_TRUSTED_PREFIX_LEN + name_len + 1;

+ if (!capable(CAP_SYS_ADMIN))
+ return 0;
+
if (list && retlen<=list_size) {
strcpy(list, XATTR_TRUSTED_PREFIX);
strcpy(list + XATTR_TRUSTED_PREFIX_LEN, name);
--
1.6.3.3

== 4 of 4 ==
Date: Tues, Mar 2 2010 12:30 am
From: Andreas Dilger

On 2010-03-02, at 01:01, James Morris wrote:
> I noticed that there are differences in the behavior of listxattr(2)
> for
> xattrs in the trusted namespace.
>
> Some filesystems, such as ext[234], require CAP_SYS_ADMIN for this,
> i.e.
> trusted xattr names are hidden from unprivileged users.

This matches my understanding of the trusted.* namespace. It is
settable by the kernel and root (CAP_SYS_ADMIN) but not regular users.

> I'm not sure what the initial intention was for the behavior, although
> given that several major filesystems are have been fielded with the
> CAP_SYS_ADMIN check, it seems most prudent to make this the standard
> behavior for all filesystems, in case any users are depending on it.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

==============================================================================
TOPIC: memcg: dirty pages instrumentation
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 12:10 am
From: Andrea Righi

On Tue, Mar 02, 2010 at 09:23:09AM +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 1 Mar 2010 22:23:40 +0100
> Andrea Righi <arighi@develer.com> wrote:
>
> > Apply the cgroup dirty pages accounting and limiting infrastructure to
> > the opportune kernel functions.
> >
> > Signed-off-by: Andrea Righi <arighi@develer.com>
>
> Seems nice.
>
> Hmm. the last problem is moving account between memcg.
>
> Right ?

Correct. This was actually the last item of the TODO list. Anyway, I'm
still considering if it's correct to move dirty pages when a task is
migrated from a cgroup to another. Currently, dirty pages just remain in
the original cgroup and are flushed depending on the original cgroup
settings. That is not totally wrong... at least moving the dirty pages
between memcgs should be optional (move_charge_at_immigrate?).

Thanks for your ack and the detailed review!

-Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Mar 2 2010 12:20 am
From: Daisuke Nishimura

On Tue, 2 Mar 2010 09:01:58 +0100, Andrea Righi <arighi@develer.com> wrote:
> On Tue, Mar 02, 2010 at 09:23:09AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Mon, 1 Mar 2010 22:23:40 +0100
> > Andrea Righi <arighi@develer.com> wrote:
> >
> > > Apply the cgroup dirty pages accounting and limiting infrastructure to
> > > the opportune kernel functions.
> > >
> > > Signed-off-by: Andrea Righi <arighi@develer.com>
> >
> > Seems nice.
> >
> > Hmm. the last problem is moving account between memcg.
> >
> > Right ?
>
> Correct. This was actually the last item of the TODO list. Anyway, I'm
> still considering if it's correct to move dirty pages when a task is
> migrated from a cgroup to another. Currently, dirty pages just remain in
> the original cgroup and are flushed depending on the original cgroup
> settings. That is not totally wrong... at least moving the dirty pages
> between memcgs should be optional (move_charge_at_immigrate?).
>
FYI, I'm planning to add file-cache and shmem/tmpfs support for move_charge feature
for 2.6.35.
But, hmm, it would be complicated if we try to move dirty account too.

Thanks,
Daisuke Nishimura.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Tues, Mar 2 2010 12:30 am
From: KAMEZAWA Hiroyuki

On Tue, 2 Mar 2010 09:01:58 +0100
Andrea Righi <arighi@develer.com> wrote:

> On Tue, Mar 02, 2010 at 09:23:09AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Mon, 1 Mar 2010 22:23:40 +0100
> > Andrea Righi <arighi@develer.com> wrote:
> >
> > > Apply the cgroup dirty pages accounting and limiting infrastructure to
> > > the opportune kernel functions.
> > >
> > > Signed-off-by: Andrea Righi <arighi@develer.com>
> >
> > Seems nice.
> >
> > Hmm. the last problem is moving account between memcg.
> >
> > Right ?
>
> Correct. This was actually the last item of the TODO list. Anyway, I'm
> still considering if it's correct to move dirty pages when a task is
> migrated from a cgroup to another. Currently, dirty pages just remain in
> the original cgroup and are flushed depending on the original cgroup
> settings. That is not totally wrong... at least moving the dirty pages
> between memcgs should be optional (move_charge_at_immigrate?).
>

My concern is
- migration between memcg is already suppoted
- at task move
- at rmdir

Then, if you leave DIRTY_PAGE accounting to original cgroup,
the new cgroup (migration target)'s Dirty page accounting may
goes to be negative, or incorrect value. Please check FILE_MAPPED
implementation in __mem_cgroup_move_account()

As
if (page_mapped(page) && !PageAnon(page)) {
/* Update mapped_file data for mem_cgroup */
preempt_disable();
__this_cpu_dec(from->stat->count[MEM_CGROUP_STAT_FILE_MAPPED]);
__this_cpu_inc(to->stat->count[MEM_CGROUP_STAT_FILE_MAPPED]);
preempt_enable();
}
then, FILE_MAPPED never goes negative.

Thanks,
-Kame

> Thanks for your ack and the detailed review!
>
> -Andrea
>
> --
> 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>
>

==============================================================================
TOPIC: use of setjmp/longjmp in x86 emulator.
http://groups.google.com/group/linux.kernel/t/7b2acc7ec923cec7?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:10 am
From: Gleb Natapov

On Mon, Mar 01, 2010 at 01:34:42PM -1000, Zachary Amsden wrote:
> On 03/01/2010 12:56 PM, H. Peter Anvin wrote:
> >On 03/01/2010 02:31 PM, H. Peter Anvin wrote:
> >>On 03/01/2010 11:18 AM, Zachary Amsden wrote:
> >>>It's going to be ugly to emulate segmentation, NX and write protect
> >>>support without hardware to do this checking for you, but it's just what
> >>>you have to do in this slow path - tedious, fully specified emulation.
> >>>
> >>>Just because it's tedious doesn't mean we need to use setjmp / longjmp.
> >>>Throw / catch might be effective, but it's still pretty bizarre to do
> >>>tricks like that in C.
> >>>
> >>Well, setjmp/longjmp really is not much more than exception handling in C.
> >>
> >For what it's worth, I think that setjmp/longjmp is not anywhere near as
> >dangerous as people want to make it out to be. gcc will warn for
> >dangerous uses (and a lot of non-dangerous uses), but generally the
> >difficult problems can be dealt with by moving the setjmp-protected code
> >into a separate function.
>
> I'd be curious to see if it would need to evolve it to preemptsetjmp
> / irqlongjmp or some other more complex forms in time.
>
Just don't allow stupid usage of longjmp. Like everything else
it can be abused.

> But I'd rather implement a new language where acquisition of
> resources such as locks, dynamically allocated objects, and ref
> counts are predicated in the function typing and are heavily
> encouraged to possess defined inverses. Then the closure of a
> particular layer of nesting already has enough information to
> provide release upon escape, and the compiler can easily take the
> burden of checking for a large class of lock and resource violation.
>
> And it would have to be prettier than the current languages that do
> that, meaning operator overloading would be banned. Although it
> would define rational numbers, super-extended precision arithmetic,
> imaginary numbers, quaternions and matrices as part of the spec, so
> there would be no need to use arithmetic overrides anyway, and then
> all the nonsensical operators could die, die, die, especially the
> function () and logical operator overrides.
>
Will you language have a lot of parentheses?

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: drivers: net: optimize hex2bin()
http://groups.google.com/group/linux.kernel/t/766d35ce753992f1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:10 am
From: Andy Shevchenko

From: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>

Optimize hex2bin() function used in ps3_gelic_wireless.c. It requires to have
hex_to_bin() implementation introduced by starter patch [1] in series.

[1] http://patchwork.kernel.org/patch/81224/

Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
Cc: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/net/ps3_gelic_wireless.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ps3_gelic_wireless.c b/drivers/net/ps3_gelic_wireless.c
index 227b141..7c3d7f1 100644
--- a/drivers/net/ps3_gelic_wireless.c
+++ b/drivers/net/ps3_gelic_wireless.c
@@ -1394,23 +1394,20 @@ static int gelic_wl_get_mode(struct net_device *netdev,
static int hex2bin(u8 *str, u8 *bin, unsigned int len)
{
unsigned int i;
- static unsigned char *hex = "0123456789ABCDEF";
- unsigned char *p, *q;
- u8 tmp;

if (len != WPA_PSK_LEN * 2)
return -EINVAL;

for (i = 0; i < WPA_PSK_LEN * 2; i += 2) {
- p = strchr(hex, toupper(str[i]));
- q = strchr(hex, toupper(str[i + 1]));
- if (!p || !q) {
+ int h = hex_to_bin(str[i]);
+ int l = hex_to_bin(str[i+1]);
+
+ if ((h == -1) || (l == -1)) {
pr_info("%s: unconvertible PSK digit=%d\n",
__func__, i);
return -EINVAL;
}
- tmp = ((p - hex) << 4) + (q - hex);
- *bin++ = tmp;
+ *bin++ = (h << 4) + l;
}
return 0;
};
--
1.5.6.5

==============================================================================
TOPIC: mm: use the same log level for show_mem()
http://groups.google.com/group/linux.kernel/t/42909485541f85ca?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:20 am
From: Amerigo Wang

Use the same log level for printk's in show_mem(),
so that those messages can be shown completely
when using log level 6.

Signed-off-by: WANG Cong <amwang@redhat.com>

---
diff --git a/lib/show_mem.c b/lib/show_mem.c
index 238e72a..fdc77c8 100644
--- a/lib/show_mem.c
+++ b/lib/show_mem.c
@@ -15,7 +15,7 @@ void show_mem(void)
unsigned long total = 0, reserved = 0, shared = 0,
nonshared = 0, highmem = 0;

- printk(KERN_INFO "Mem-Info:\n");
+ printk("Mem-Info:\n");
show_free_areas();

for_each_online_pgdat(pgdat) {
@@ -49,15 +49,15 @@ void show_mem(void)
pgdat_resize_unlock(pgdat, &flags);
}

- printk(KERN_INFO "%lu pages RAM\n", total);
+ printk("%lu pages RAM\n", total);
#ifdef CONFIG_HIGHMEM
- printk(KERN_INFO "%lu pages HighMem\n", highmem);
+ printk("%lu pages HighMem\n", highmem);

twitter

Tuesday, March 2, 2010

linux.kernel - 20 new messages in 13 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts