[PATCH 5/9] block: Gut bio_add_page(), kill bio_add_pc_page()
Since generic_make_request() can now handle arbitrary size bios, all we
have to do is make sure the bvec array doesn't overflow.
Signed-off-by: Kent Overstreet k...@daterainc.com
---
drivers/scsi/osd/osd_initiator.c | 5 +-
drivers/target/target_core_pscsi.c | 5 +-
fs/bio.c | 158 +++--
fs/exofs/ore.c | 8 +-
fs/exofs/ore_raid.c| 8 +-
include/linux/bio.h| 2 -
6 files changed, 37 insertions(+), 149 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index bac04c2..e52b30d 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -1043,7 +1043,6 @@ EXPORT_SYMBOL(osd_req_read_sg);
static struct bio *_create_sg_bios(struct osd_request *or,
void **buff, const struct osd_sg_entry *sglist, unsigned numentries)
{
- struct request_queue *q = osd_request_queue(or-osd_dev);
struct bio *bio;
unsigned i;
@@ -1060,9 +1059,9 @@ static struct bio *_create_sg_bios(struct osd_request *or,
unsigned added_len;
BUG_ON(offset + len PAGE_SIZE);
- added_len = bio_add_pc_page(q, bio, page, len, offset);
+ added_len = bio_add_page(bio, page, len, offset);
if (unlikely(len != added_len)) {
- OSD_DEBUG(bio_add_pc_page len(%d) != added_len(%d)\n,
+ OSD_DEBUG(bio_add_page len(%d) != added_len(%d)\n,
len, added_len);
bio_put(bio);
return ERR_PTR(-ENOMEM);
diff --git a/drivers/target/target_core_pscsi.c
b/drivers/target/target_core_pscsi.c
index 551c96c..d65d512 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -922,12 +922,11 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl,
u32 sgl_nents,
tbio = tbio-bi_next = bio;
}
- pr_debug(PSCSI: Calling bio_add_pc_page() i: %d
+ pr_debug(PSCSI: Calling bio_add_page() i: %d
bio: %p page: %p len: %d off: %d\n, i, bio,
page, len, off);
- rc = bio_add_pc_page(pdv-pdv_sd-request_queue,
- bio, page, bytes, off);
+ rc = bio_add_page(bio, page, bytes, off);
if (rc != bytes)
goto fail;
diff --git a/fs/bio.c b/fs/bio.c
index 7d538a1..c60bfcb 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -665,12 +665,22 @@ int bio_get_nr_vecs(struct block_device *bdev)
}
EXPORT_SYMBOL(bio_get_nr_vecs);
-static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
- *page, unsigned int len, unsigned int offset,
- unsigned short max_sectors)
+/**
+ * bio_add_page- attempt to add page to bio
+ * @bio: destination bio
+ * @page: page to add
+ * @len: vec entry length
+ * @offset: vec entry offset
+ *
+ * Attempt to add a page to the bio_vec maplist. This can fail for a
+ * number of reasons, such as the bio being full or target block device
+ * limitations. The target block device must allow bio's up to PAGE_SIZE,
+ * so it is always possible to add a single page to an empty bio.
+ */
+int bio_add_page(struct bio *bio, struct page *page,
+unsigned int len, unsigned int offset)
{
- int retried_segments = 0;
- struct bio_vec *bvec;
+ struct bio_vec *bv;
/*
* cloned bio must not modify vec list
@@ -678,41 +688,17 @@ static int __bio_add_page(struct request_queue *q, struct
bio *bio, struct page
if (unlikely(bio_flagged(bio, BIO_CLONED)))
return 0;
- if (((bio-bi_iter.bi_size + len) 9) max_sectors)
- return 0;
-
/*
* For filesystems with a blocksize smaller than the pagesize
* we will often be called with the same page as last time and
* a consecutive offset. Optimize this special case.
*/
if (bio-bi_vcnt 0) {
- struct bio_vec *prev = bio-bi_io_vec[bio-bi_vcnt - 1];
-
- if (page == prev-bv_page
- offset == prev-bv_offset + prev-bv_len) {
- unsigned int prev_bv_len = prev-bv_len;
- prev-bv_len += len;
-
- if (q-merge_bvec_fn) {
- struct bvec_merge_data bvm = {
- /* prev_bvec is already charged in
- bi_size, discharge it in order to
- simulate merging updated prev_bvec
- as
Re: [PATCH 03/14] perf hists: Convert hist entry functions to use struct he_stat
Em Thu, Oct 31, 2013 at 03:56:05PM +0900, Namhyung Kim escreveu:
-static void hist_entry__add_cpumode_period(struct hist_entry *he,
+static void hist_entry__add_cpumode_period(struct he_stat *he_stat,
unsigned int cpumode, u64 period)
So it is not anymore a 'struct hist_entry' method, but a 'struct
he_stat' one, thus these functions need to be renamed accordingly, in
the above case it should be:
-static void hist_entry__add_cpumode_period(struct hist_entry *he,
+static void he_stat__add_cpumode_period(struct he_stat *he_stat,
+unsigned int cpumode, u64 period)
{
switch (cpumode) {
case PERF_RECORD_MISC_KERNEL:
- he-stat.period_sys += period;
+ he_stat-period_sys += period;
break;
case PERF_RECORD_MISC_USER:
- he-stat.period_us += period;
+ he_stat-period_us += period;
break;
case PERF_RECORD_MISC_GUEST_KERNEL:
- he-stat.period_guest_sys += period;
+ he_stat-period_guest_sys += period;
break;
case PERF_RECORD_MISC_GUEST_USER:
- he-stat.period_guest_us += period;
+ he_stat-period_guest_us += period;
break;
default:
break;
@@ -223,10 +223,10 @@ static void he_stat__add_stat(struct he_stat *dest,
struct he_stat *src)
dest-weight+= src-weight;
}
-static void hist_entry__decay(struct hist_entry *he)
+static void hist_entry__decay(struct he_stat *he_stat)
Ditto
{
- he-stat.period = (he-stat.period * 7) / 8;
- he-stat.nr_events = (he-stat.nr_events * 7) / 8;
+ he_stat-period = (he_stat-period * 7) / 8;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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.10.16 general protection fault kmem_cache_alloc+0x67/0x170
I had a machine crash this weekend running a 3.10.16 kernel that additionally has a few backported networking patches for performance improvements. At this point I can't rule out that the bug isn't from those patches, and I haven't yet tried to see if I can reproduce the crash. I did happen to have kdump configured so I've got a crash dump that I've been poking at but I'm not an expert here so hopefully someone can provide some guidance on what I'm looking at and/or where the bug might be. Below is the more detailed info with some of my comments interspersed. If anyone has any questions or suggestions I'd appreciate it. [1448642.601229] general protection fault: [#1] SMP [1448642.602448] Modules linked in: mpt2sas scsi_transport_sas raid_class mptctl mptbase dell_rbu ipmi_devintf ipmi_si ipmi_msghandler lockd 8021q mrp garp stp llc ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_addr iw_cxgb3 mlx4_ib ib_sa ib_mad ib_core mlx4_en ext4 jbd2 mbcache joydev fuse ses bnx2 coretemp mlx4_core cxgb3 hwmon mdio enclosure iTCO_wdt iTCO_vendor_support freq_table mperf wmi ehci_pci ehci_hcd dcdbas serio_raw microcode lpc_ich mfd_core sunrpc ipv6 autofs4 crc32c_intel megaraid_sas uhci_hcd dm_mirror dm_region_hash dm_log dm_mod [1448642.616810] CPU: 11 PID: 27807 Comm: primary_nic_is_ Not tainted 3.10.16-1.rgm.fc16.x86_64 #1 [1448642.618941] Hardware name: Dell Inc. PowerEdge R610/0XDN97, BIOS 6.3.0 07/24/2012 [1448642.620639] task: 8806628c3880 ti: 88060437 task.ti: 88060437 [1448642.622335] RIP: 0010:[8112b117] [8112b117] kmem_cache_alloc+0x67/0x170 [1448642.624286] RSP: 0018:880604371d70 EFLAGS: 00010282 [1448642.625500] RAX: RBX: 8806628c3880 RCX: 7ecb996a [1448642.627415] RDX: 7ecb9969 RSI: 00d0 RDI: 00015900 [1448642.629077] RBP: 880604371dc0 R08: 880667d55900 R09: [1448642.630697] R10: R11: 00015ea8 R12: 880c67003800 [1448642.632316] R13: d17b94d6641aebfb R14: 81064d68 R15: 00d0 [1448642.633936] FS: 7f8018827700() GS:880667d4() knlGS: [1448642.635768] CS: 0010 DS: ES: CR0: 8005003b [1448642.637497] CR2: 006eded4 CR3: 00066368b000 CR4: 07e0 [1448642.639230] DR0: DR1: DR2: [1448642.640849] DR3: DR6: 0ff0 DR7: 0400 [1448642.642468] Stack: [1448642.642950] ff9c 8806628c3880 8806628c3880 0002 [1448642.644780] 8806628c3880 8806628c3880 01200011 [1448642.646848] 7f80188279d0 880604371de0 81064d68 [1448642.648987] Call Trace: [1448642.649568] [81064d68] prepare_creds+0x28/0x160 [1448642.650822] [81065436] copy_creds+0x36/0x160 [1448642.652019] [810393e0] copy_process+0x310/0x14b0 [1448642.653295] [811534f5] ? __alloc_fd+0x45/0x110 [1448642.654529] [8103a64c] do_fork+0x9c/0x280 [1448642.655668] [811535f0] ? get_unused_fd_flags+0x30/0x40 [1448642.657473] [8114147f] ? __do_pipe_flags+0x7f/0xc0 [1448642.658808] [8115362b] ? __fd_install+0x2b/0x60 [1448642.660062] [8103a8b6] SyS_clone+0x16/0x20 [1448642.661222] [814c2429] stub_clone+0x69/0x90 [1448642.662399] [814c2182] ? system_call_fastpath+0x16/0x1b [1448642.663807] Code: 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 f7 00 00 00 48 85 c0 0f 84 ee 00 00 00 49 63 44 24 20 48 8d 4a 01 49 8b 3c 24 49 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b5 49 [1448642.671081] RIP [8112b117] kmem_cache_alloc+0x67/0x170 [1448642.672508] RSP 880604371d70 [1448642.673330] ---[ end trace fe4b503d6f77c801 ]--- [1448642.674408] general protection fault: [#2] SMP [1448642.675623] Modules linked in: mpt2sas scsi_transport_sas raid_class mptctl mptbase dell_rbu ipmi_devintf ipmi_si ipmi_msghandler lockd 8021q mrp garp stp llc ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_addr iw_cxgb3 mlx4_ib ib_sa ib_mad ib_core mlx4_en ext4 jbd2 mbcache joydev fuse ses bnx2 coretemp mlx4_core cxgb3 hwmon mdio enclosure iTCO_wdt iTCO_vendor_support freq_table mperf wmi ehci_pci ehci_hcd dcdbas serio_raw microcode lpc_ich mfd_core sunrpc ipv6 autofs4 crc32c_intel megaraid_sas uhci_hcd dm_mirror dm_region_hash dm_log dm_mod [1448642.690185] CPU: 11 PID: 27807 Comm: primary_nic_is_ Tainted: G D 3.10.16-1.rgm.fc16.x86_64 #1 [1448642.692328] Hardware name: Dell Inc. PowerEdge R610/0XDN97, BIOS 6.3.0 07/24/2012 [1448642.694027] task: 8806628c3880 ti: 88060437 task.ti: 88060437 [1448642.695726] RIP: 0010:[8112b117] [8112b117] kmem_cache_alloc+0x67/0x170 [1448642.698133] RSP: 0018:880667d43ad0 EFLAGS: 00010282
Re: [PATCH 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
On 11/04/2013 04:26 PM, Heiko Stübner wrote:
I remember we had a discussion about how things like bias-disable explicitly
shouldn't have a value, when they are represented in the list-format:
pcfg_pull_none: pcfg_pull_none {
bias-disable;
};
so a bias-disable = 1 was explicitly forbidden [for a lack of a better
word]. And it was similar for other options, the parameter not meant to be
indicating if they are active but really only setting the strength or so.
Pure Boolean values should be represented as a valueless property. If
the property is present, the value is true, otherwise false.
However, pinctrl bindings often don't represent Boolean values, but
rather tri-states, with the following values:
* Don't touch this configuration option at all (missing)
* Enable the option (1)
* Disable the option (0)
The reason for using tri-states being that you might want to write:
xxx1 {
pins = PINA, PINB, PINC;
function = ...;
// this node doesn't affect pullup
}
xxx2 {
pins = PINA, PINB;
// this node doesn't affect function
pull-up = 1; // change, and enable
}
xxx3 {
pins = PINAC;
// this node doesn't affect function
pull-up = 0; // change, and disable
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH 4/9] block: Make generic_make_request handle arbitrary sized bios
On 11/04/2013 03:36 PM, Kent Overstreet wrote:
@@ -1822,6 +1820,14 @@ void generic_make_request(struct bio *bio)
*/
blk_queue_bounce(q, bio);
+ if (!blk_queue_largebios(q))
+ split = blk_bio_segment_split(q, bio, q-bio_split);
Is it assumed bios coming down this path are created using bio_add_page?
If not, does blk_bio_segment_split need a queue_max_sectors or
queue_max_hw_sectors check? I only saw a segment count check below.
+
+struct bio *blk_bio_segment_split(struct request_queue *q, struct bio *bio,
+ struct bio_set *bs)
+{
+ struct bio *split;
+ struct bio_vec bv, bvprv;
+ struct bvec_iter iter;
+ unsigned seg_size = 0, nsegs = 0;
+ int prev = 0;
+
+ struct bvec_merge_data bvm = {
+ .bi_bdev= bio-bi_bdev,
+ .bi_sector = bio-bi_iter.bi_sector,
+ .bi_size= 0,
+ .bi_rw = bio-bi_rw,
+ };
+
+ if (bio-bi_rw REQ_DISCARD)
+ return blk_bio_discard_split(q, bio, bs);
+
+ if (bio-bi_rw REQ_WRITE_SAME)
+ return blk_bio_write_same_split(q, bio, bs);
+
+ bio_for_each_segment(bv, bio, iter) {
+ if (q-merge_bvec_fn
+ q-merge_bvec_fn(q, bvm, bv) (int) bv.bv_len)
+ goto split;
+
+ bvm.bi_size += bv.bv_len;
+
+ if (prev blk_queue_cluster(q)) {
+ if (seg_size + bv.bv_len queue_max_segment_size(q))
+ goto new_segment;
+ if (!BIOVEC_PHYS_MERGEABLE(bvprv, bv))
+ goto new_segment;
+ if (!BIOVEC_SEG_BOUNDARY(q, bvprv, bv))
+ goto new_segment;
+
+ seg_size += bv.bv_len;
+ bvprv = bv;
+ prev = 1;
+ continue;
+ }
+new_segment:
+ if (nsegs == queue_max_segments(q))
+ goto split;
+
+ nsegs++;
+ bvprv = bv;
+ prev = 1;
+ seg_size = bv.bv_len;
+ }
+
+ return NULL;
+split:
+ split = bio_clone_bioset(bio, GFP_NOIO, bs);
+
+ split-bi_iter.bi_size -= iter.bi_size;
+ bio-bi_iter = iter;
+
+ if (bio_integrity(bio)) {
+ bio_integrity_advance(bio, split-bi_iter.bi_size);
+ bio_integrity_trim(split, 0, bio_sectors(split));
+ }
+
+ return split;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] module: export sig_enforce readonly even if MODULE_SIG_FORCE is on
Even if MODULE_SIG_FORCE is turned on, it is still useful if module
can export sig_enforce, so user space will know if module signature
is turned on and forced.
Signed-off-by: Eric Miao eric.m...@nvidia.com
Cc: David Howells dhowe...@redhat.com
Cc: Dan Willemsen dwillem...@nvidia.com
---
kernel/module.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..d55646b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -110,6 +110,14 @@ struct list_head *kdb_modules = modules; /* kdb needs the
list of modules */
#ifdef CONFIG_MODULE_SIG
#ifdef CONFIG_MODULE_SIG_FORCE
static bool sig_enforce = true;
+
+static const struct kernel_param_ops param_ops_bool_read_only = {
+ .flags = KERNEL_PARAM_FL_NOARG,
+ .get = param_get_bool,
+};
+#define param_check_bool_read_only param_check_bool
+
+module_param(sig_enforce, bool_read_only, 0444);
#else
static bool sig_enforce = false;
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MODSIG: use pre-generated X.509 key by MODPUBKEY
If MODPUBKEY is specified and other than default ./signing_key.x509, use that key instead of generating one on-the-fly. Signed-off-by: Eric Miao eric.m...@nvidia.com Cc: David Howells dhowe...@redhat.com Cc: Dan Willemsen dwillem...@nvidia.com --- kernel/Makefile | 8 1 file changed, 8 insertions(+) diff --git a/kernel/Makefile b/kernel/Makefile index 1ce4755..66c7c32 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -165,6 +165,13 @@ ifndef CONFIG_MODULE_SIG_HASH $(error Could not determine digest type to use from kernel config) endif +ifneq ($(MODPUBKEY),./signing_key.x509) +signing_key.x509: $(MODPUBKEY) + @echo ### + @echo ### Use pre-generated X.509 key pair for signing modules. + @echo ### + cp -f $ $@ +else signing_key.priv signing_key.x509: x509.genkey @echo ### @echo ### Now generating an X.509 key pair to be used for signing modules. @@ -202,3 +209,4 @@ x509.genkey: @echo x509.genkey subjectKeyIdentifier=hash @echo x509.genkey authorityKeyIdentifier=keyid endif +endif -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] percpu: add test module for various percpu operations
On Sun, 27 Oct 2013 10:30:15 -0700 Greg Thelen gthe...@google.com wrote: Tests various percpu operations. Could you please take a look at the 32-bit build (this is i386): lib/percpu_test.c: In function 'percpu_test_init': lib/percpu_test.c:61: warning: integer constant is too large for 'long' type lib/percpu_test.c:61: warning: integer constant is too large for 'long' type lib/percpu_test.c:61: warning: integer constant is too large for 'long' type lib/percpu_test.c:61: warning: integer constant is too large for 'long' type lib/percpu_test.c:61: warning: integer constant is too large for 'long' type lib/percpu_test.c:61: warning: integer constant is too large for 'long' type lib/percpu_test.c:70: warning: integer constant is too large for 'long' type lib/percpu_test.c:70: warning: integer constant is too large for 'long' type lib/percpu_test.c:70: warning: integer constant is too large for 'long' type lib/percpu_test.c:70: warning: integer constant is too large for 'long' type lib/percpu_test.c:70: warning: integer constant is too large for 'long' type lib/percpu_test.c:70: warning: integer constant is too large for 'long' type lib/percpu_test.c:89: warning: integer constant is too large for 'long' type lib/percpu_test.c:89: warning: integer constant is too large for 'long' type lib/percpu_test.c:89: warning: integer constant is too large for 'long' type lib/percpu_test.c:89: warning: integer constant is too large for 'long' type lib/percpu_test.c:89: warning: integer constant is too large for 'long' type lib/percpu_test.c:89: warning: integer constant is too large for 'long' type lib/percpu_test.c:97: warning: integer constant is too large for 'long' type lib/percpu_test.c:97: warning: integer constant is too large for 'long' type lib/percpu_test.c:97: warning: integer constant is too large for 'long' type lib/percpu_test.c:97: warning: integer constant is too large for 'long' type lib/percpu_test.c:97: warning: integer constant is too large for 'long' type lib/percpu_test.c:97: warning: integer constant is too large for 'long' type lib/percpu_test.c:112: warning: integer constant is too large for 'long' type lib/percpu_test.c:112: warning: integer constant is too large for 'long' type lib/percpu_test.c:112: warning: integer constant is too large for 'long' type lib/percpu_test.c:112: warning: integer constant is too large for 'long' type lib/percpu_test.c:112: warning: integer constant is too large for 'long' type lib/percpu_test.c:112: warning: integer constant is too large for 'long' type -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mmotm 2013-11-04-16-11 uploaded
The mm-of-the-moment snapshot 2013-11-04-16-11 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the #NEXT_PATCHES_START mm and #NEXT_PATCHES_END markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master make changes, commit $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic base topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.12: (patches marked * will be included in linux-next) origin.patch arch-alpha-kernel-systblss-remove-debug-check.patch i-need-old-gcc.patch * kthread-make-kthread_create-killable.patch * sh64-kernel-use-usp-instead-of-fn.patch * sh64-kernel-remove-useless-variable-regs.patch * arch-x86-mnify-pte_to_pgoff-and-pgoff_to_pte-helpers.patch * x86-srat-use-numa_no_node.patch * x86-mm-get-aslr-work-for-hugetlb-mappings.patch * kernel-auditc-remove-duplicated-comment.patch * media-platform-drivers-fix-build-on-cris-arch.patch * drm-fb-helper-dont-sleep-for-screen-unblank-when-an-oopps-is-in-progress.patch * drm-cirrus-correct-register-values-for-16bpp.patch * drm-nouveau-make-vga_switcheroo-code-depend-on-vga_switcheroo.patch * drm-nouveau-make-vga_switcheroo-code-depend-on-vga_switcheroo-fix.patch * drivers-iommu-omap-iopgtableh-remove-unneeded-cast-of-void.patch * genirq-correct-fuzzy-and-fragile-irq_retval-definition.patch * sched_clock-document-4mhz-vs-1mhz-decision.patch * kernel-timerc-convert-kmalloc_nodegfp_zero-to-kzalloc_node.patch * kernel-time-tick-commonc-document-tick_do_timer_cpu.patch * drivers-infiniband-core-cmc-convert-to-using-idr_alloc_cyclic.patch * input-remove-unnecessary-work-pending-test.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix-3.patch * scripts-sortextable-support-objects-with-more-than-64k-sections.patch * drivers-net-irda-donauboe-convert-to-module_pci_driver.patch * fs-ocfs2-remove-unnecessary-variable-bits_wanted-from-ocfs2_calc_extend_credits.patch * fs-ocfs2-filec-fix-wrong-comment.patch * ocfs2-return-enomem-when-sb_getblk-fails.patch * ocfs2-return-enomem-when-sb_getblk-fails-update.patch * ocfs2-add-necessary-check-in-case-sb_getblk-fails.patch * ocfs2-add-necessary-check-in-case-sb_getblk-fails-update.patch * ocfs2-dont-spam-on-edquot.patch * ocfs2-use-bitmap_weight.patch * ocfs2-skip-locks-in-the-blocked-list.patch * ocfs2-delay-migration-when-the-lockres-is-in-migration-state.patch * ocfs2-use-find_last_bit.patch * ocfs2-break-useless-while-loop.patch * ocfs2-rollback-transaction-in-ocfs2_group_add.patch * ocfs2-do-not-call-brelse-if-group_bh-is-not-initialized-in-ocfs2_group_add.patch * ocfs2-add-missing-errno-in-ocfs2_ioctl_move_extents.patch * ocfs2-fix-possible-double-free-in-ocfs2_write_begin_nolock.patch * add-clustername-to-cluster-connection.patch * add-dlm-recovery-callbacks.patch *
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
Jason, On Mon, Nov 04, 2013 at 05:27:19PM -0700, Jason Gunthorpe wrote: Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node fyi: set core.abbrev = 12 in your git config, according to Linus, 7/8 was a bad decision... present' made the call to phy_scan optional, if the DT has a link to the phy node. However phy_scan has the side effect of calling phy_addr_set, which writes the phy MDIO address to the ethernet controller. If phy_addr_set is not called, and the bootloader has not set the correct address then the driver will fail to function. Tested on Kirkwood. Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com Fixes: cc9d459894b0 net: mv643xx_eth: use of_phy_connect if phy_node present Acked-by: Jason Cooper ja...@lakedaemon.net And it should be suitable for v3.11+ thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG][ext2] XIP does not work on ext2
Hello,
On Mon 04-11-13 14:31:34, Andiry Xu wrote:
When I'm trying XIP on ext2, I find that xip does not work on ext2
with latest kernel.
Reproduce steps:
Compile kernel with following configs:
CONFIG_BLK_DEV_XIP=y
CONFIG_EXT2_FS_XIP=y
And run following commands:
# mke2fs -b 4096 /dev/ram0
# mount -t ext2 -o xip /dev/ram0 /mnt/ramdisk/
# dd if=/dev/zero of=/mnt/ramdisk/test1 bs=1M count=16
And it shows:
dd: writing `/mnt/ramdisk/test1': No space left on device
df also shows /mnt/ramdisk is 100% full. Its default size is 64MB so a
16MB write should only occupy 1/4 capacity.
Criminal commit:
After git bisect, it points to the following commit:
8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b
Ext2: mark inode dirty after the function dquot_free_block_nodirty is called
Thanks for report and the bisection!
Particularly, the following code:
@@ -1412,9 +1415,11 @@ allocated:
*errp = 0;
brelse(bitmap_bh);
-dquot_free_block_nodirty(inode, *count-num);
-mark_inode_dirty(inode);
-*count = num;
+if (num *count) {
+dquot_free_block_nodirty(inode, *count-num);
+mark_inode_dirty(inode);
+*count = num;
+}
return ret_block;
Not mark_inode_dirty() is called only when num is less than *count.
However, I've seen
with the dd command, there is case where num = *count.
Fix:
I've verified that the following patch fixes the issue:
diff --git a/fs/ext2/balloc.c b/fs/ext2/balloc.c
index 9f9992b..5446a52 100644
--- a/fs/ext2/balloc.c
+++ b/fs/ext2/balloc.c
@@ -1406,11 +1406,10 @@ allocated:
*errp = 0;
brelse(bitmap_bh);
- if (num *count) {
+ if (num = *count)
dquot_free_block_nodirty(inode, *count-num);
- mark_inode_dirty(inode);
- *count = num;
- }
+ mark_inode_dirty(inode);
+ *count = num;
return ret_block;
io_error:
However, I'm not familiar with ext2 source code and cannot tell if
this is the correct fix. At least it fixes my issue.
With this, you have essentially reverted a hunk from commit
8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b. But I don't see a reason why it
should be reverted. num should never ever be greater than *count and when
num == count, we the code inside if doesn't do anything useful.
I've looked into the code and I think I see the problem. It is a long
standing bug in __ext2_get_block() in fs/ext2/xip.c. It calls
ext2_get_block() asking for 0 blocks to map (while we really want 1 block).
ext2_get_block() just passes that request and ext2_get_blocks() actually
allocates 1 block. And that's were the commit you have identified makes a
difference because previously we returned that 1 block was allocated while
now we return that 0 blocks were allocated and thus allocation is repeated
until all free blocks are exhaused.
Attached patch should fix the problem.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
From ce14b6595c9f23db4a3fbeccd921f0687c9c73d4 Mon Sep 17 00:00:00 2001
From: Jan Kara j...@suse.cz
Date: Tue, 5 Nov 2013 01:15:38 +0100
Subject: [PATCH] ext2: Fix fs corruption in ext2_get_xip_mem()
Commit 8e3dffc651cb Ext2: mark inode dirty after the function
dquot_free_block_nodirty is called unveiled a bug in __ext2_get_block()
called from ext2_get_xip_mem(). That function called ext2_get_block()
mistakenly asking it to map 0 blocks while 1 was intended. Before the
above mentioned commit things worked out fine by luck but after that commit
we started returning that we allocated 0 blocks while we in fact
allocated 1 block and thus allocation was looping until all blocks in
the filesystem were exhausted.
Fix the problem by properly asking for one block and also add assertion
in ext2_get_blocks() to catch similar problems.
Signed-off-by: Jan Kara j...@suse.cz
---
fs/ext2/inode.c | 2 ++
fs/ext2/xip.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index c260de6d7b6d..8a337640a46a 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -632,6 +632,8 @@ static int ext2_get_blocks(struct inode *inode,
int count = 0;
ext2_fsblk_t first_block = 0;
+ BUG_ON(maxblocks == 0);
+
depth = ext2_block_to_path(inode,iblock,offsets,blocks_to_boundary);
if (depth == 0)
diff --git a/fs/ext2/xip.c b/fs/ext2/xip.c
index 1c3312858fcf..e98171a11cfe 100644
--- a/fs/ext2/xip.c
+++ b/fs/ext2/xip.c
@@ -35,6 +35,7 @@ __ext2_get_block(struct inode *inode, pgoff_t pgoff, int create,
int rc;
memset(tmp, 0, sizeof(struct buffer_head));
+ tmp.b_size = 1 inode-i_blkbits;
rc = ext2_get_block(inode, pgoff, tmp, create);
*result = tmp.b_blocknr;
--
1.8.1.4
Re: [PATCH 0/3] mm,vdso: preallocate new vmas
Hi Andrew - On Thu, 2013-10-17 at 17:50 -0700, Davidlohr Bueso wrote: Linus recently pointed out[1] some of the amount of unnecessary work being done with the mmap_sem held. This patchset is a very initial approach on reducing some of the contention on this lock, and moving work outside of the critical region. Patch 1 adds a simple helper function. Patch 2 moves out some trivial setup logic in mlock related calls. Patch 3 allows managing new vmas without requiring the mmap_sem for vdsos. While it's true that there are many other scenarios where this can be done, few are actually as straightforward as this in the sense that we *always* end up allocating memory anyways, so there's really no tradeoffs. For this reason I wanted to get this patch out in the open. If you have no objections, could you pickup patches 1 and 2? I think it's safe to say that patch 3 isn't worth any more discussion. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Virtual Online Assistant Needed !!
-- Hi There, Recruitment of a Mystery-Shopper Get Paid, $200 per-assignment. If Interested Reply us Immediately. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] fs/ext3: use rbtree postorder iteration helper instead of opencoding
On Mon 04-11-13 15:26:38, Jan Kara wrote:
On Fri 01-11-13 15:38:50, Cody P Schafer wrote:
Use rbtree_postorder_for_each_entry_safe() to destroy the rbtree instead
of opencoding an alternate postorder iteration that modifies the tree
Thanks. I've merged the patch into my tree.
Hum, except that the kernel oopses with this patch. And I think the
problem is in rbtree_postorder_for_each_entry_safe(). How are those tests
for NULL supposed to work? For example if the tree is empty, 'pos' will be
NULL and you'll call rb_next_postorder(NULL-field) which is pretty much
guaranteed to oops if 'field' doesn't have offset 0 in the structure...
Honza
Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com
---
fs/ext3/dir.c | 36 +---
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/fs/ext3/dir.c b/fs/ext3/dir.c
index bafdd48..a331ad1 100644
--- a/fs/ext3/dir.c
+++ b/fs/ext3/dir.c
@@ -309,43 +309,17 @@ struct fname {
*/
static void free_rb_tree_fname(struct rb_root *root)
{
- struct rb_node *n = root-rb_node;
- struct rb_node *parent;
- struct fname*fname;
-
- while (n) {
- /* Do the node's children first */
- if (n-rb_left) {
- n = n-rb_left;
- continue;
- }
- if (n-rb_right) {
- n = n-rb_right;
- continue;
- }
- /*
-* The node has no children; free it, and then zero
-* out parent's link to it. Finally go to the
-* beginning of the loop and try to free the parent
-* node.
-*/
- parent = rb_parent(n);
- fname = rb_entry(n, struct fname, rb_hash);
+ struct fname *fname, *next;
+
+ rbtree_postorder_for_each_entry_safe(fname, next, root, rb_hash)
while (fname) {
struct fname * old = fname;
fname = fname-next;
kfree (old);
}
- if (!parent)
- *root = RB_ROOT;
- else if (parent-rb_left == n)
- parent-rb_left = NULL;
- else if (parent-rb_right == n)
- parent-rb_right = NULL;
- n = parent;
- }
-}
+ *root = RB_ROOT;
+}
static struct dir_private_info *ext3_htree_create_dir_info(struct file
*filp,
loff_t pos)
--
1.8.4.2
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling in-memory write cache for x86-64 in Linux II
On Oct 25, 2013, at 2:18 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov t.ar...@lycos.com wrote: On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel built for the i686 (with PAE) and x86-64 architectures. What’s really troubling me is that the x86-64 kernel has the following problem: When I copy large files to any storage device, be it my HDD with ext4 partitions or flash drive with FAT32 partitions, the kernel first caches them in memory entirely then flushes them some time later (quite unpredictably though) or immediately upon invoking sync. Yeah, I think we default to a 10% dirty background memory (and allows up to 20% dirty), so on your 16GB machine, we allow up to 1.6GB of dirty memory for writeout before we even start writing, and twice that before we start *waiting* for it. On 32-bit x86, we only count the memory in the low 1GB (really actually up to about 890MB), so 10% dirty really means just about 90MB of buffering (and a hard limit of ~180MB of dirty). And that up to 3.2GB of dirty memory is just crazy. Our defaults come from the old days of less memory (and perhaps servers that don't much care), and the fact that x86-32 ends up having much lower limits even if you end up having more memory. I think the “delay writes for a long time” is a holdover from the days when e.g. /tmp was on a disk and compilers had lousy IO patterns, then they deleted the file. Today, /tmp is always in RAM, and IMHO the “write and delete” workload tested by dbench is not worthwhile optimizing for. With Lustre, we’ve long taken the approach that if there is enough dirty data on a file to make a decent write (which is around 8MB today even for very fast storage) then there isn’t much point to hold back for more data before starting the IO. Any decent allocator will be able to grow allocated extents to handle following data, or allocate a new extent. At 4-8MB extents, even very seek-impaired media could do 400-800MB/s (likely much faster than the underlying storage anyway). This also avoids wasting (tens of?) seconds of idle disk bandwidth. If the disk is already busy, then the IO will be delayed anyway. If it is not busy, then why aggregate GB of dirty data in memory before flushing it? Something simple like “start writing at 16MB dirty on a single file” would probably avoid a lot of complexity at little real-world cost. That shouldn’t throttle dirtying memory above 16MB, but just start writeout much earlier than it does today. Cheers, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] trace-cmd: Make read nonblocking in find_time_stamp().
This only affects the tsc - time of day correlation when doing
`trace-cmd record --date`.
get_date_to_ts() writes a dummy event to trace_marker and then reads it back.
Reading it back is done by looping over all per-cpu raw trace pipes and trying
to read. This read should be non-blocking, because the dummy event can end up
on any CPU.
Signed-off-by: Aaron Fabbri ajfab...@gmail.com
---
trace-record.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace-record.c b/trace-record.c
index 1b1d293..dca8a92 100644
--- a/trace-record.c
+++ b/trace-record.c
@@ -2092,7 +2092,7 @@ static unsigned long long find_time_stamp(struct
pevent *pevent)
continue;
sprintf(file, %s/%s/trace_pipe_raw, path, name);
- fd = open(file, O_RDONLY);
+ fd = open(file, O_RDONLY | O_NONBLOCK);
if (fd 0)
continue;
do {
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] libata: use sleep instead of standby command
The ATA SLEEP mode saves some more power than SUSPEND, and has basically the same recovery time, so use it instead. Signed-off-by: Phillip Susi ps...@ubuntu.com --- drivers/ata/libata-scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 97a0cef..79b75fd 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1362,8 +1362,8 @@ static unsigned int ata_scsi_start_stop_xlat(struct ata_queued_cmd *qc) system_entering_hibernation()) goto skip; - /* Issue ATA STANDBY IMMEDIATE command */ - tf-command = ATA_CMD_STANDBYNOW1; + /* Issue ATA SLEEP command */ + tf-command = ATA_CMD_SLEEP; } /* -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Tick: Introduce tick_nohz_check() to check nohz enable status
On 2013年11月04日 17:52, Paul E. McKenney wrote:
On Mon, Nov 04, 2013 at 11:13:12AM +0800, Lan Tianyu wrote:
On 2013年10月29日 18:29, Lan Tianyu wrote:
On 10/29/2013 05:51 PM, Paul E. McKenney wrote:
On Tue, Oct 29, 2013 at 04:48:56PM +0800, Lan Tianyu wrote:
In some cases, nohz enable status needs to be checked. E.G, in RCU
and cpufreq
ondemand governor. So add tick_nohz_check() to return
tick_nohz_enabled value
And use tick_nohz_check() instead of referencing tick_nohz_enabled in
the rcutree_plugin.h.
Signed-off-by: Lan Tianyu tianyu@intel.com
NACK on the rcutree change unless you put the ACCESS_ONCE() in.
Or is there some reason that ACCESS_ONCE() is not needed? If so, what
is that reason?
Hi Paul:
Thanks for review. When I change this code, I find the tick_nohz_enabled
isn't changed dynamically. It's only changed during parsing kernel
params when nohz=off/on is set. Except this, it will not be changed.
So I ignored ACCESS_ONCE(). If necessary, I can add it back.
Hi Paul:
Does this reason make sense to you? Or you still prefer to add
ACCESS_ONCE() in the new tick_nohz_check()?
I prefer the ACCESS_ONCE(). It adds little or no overhead, and Frederic
has been heard to say that he mkight allow tick_nohz_check() to change
in the future.
Ok. I will update it.
Thanx, Paul
---
include/linux/tick.h | 2 ++
kernel/rcutree_plugin.h | 4 +---
kernel/time/tick-sched.c | 8 +++-
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 5128d33..a9c5374 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -136,6 +136,7 @@ static inline int tick_nohz_tick_stopped(void)
extern void tick_nohz_idle_enter(void);
extern void tick_nohz_idle_exit(void);
extern void tick_nohz_irq_exit(void);
+extern int tick_nohz_check(void);
extern ktime_t tick_nohz_get_sleep_length(void);
extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
@@ -155,6 +156,7 @@ static inline ktime_t
tick_nohz_get_sleep_length(void)
return len;
}
+static inline int tick_nohz_check(void) { return 0; }
static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) {
return -1; }
static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) {
return -1; }
# endif /* !CONFIG_NO_HZ_COMMON */
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 130c97b..af167ec 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1627,8 +1627,6 @@ module_param(rcu_idle_gp_delay, int, 0644);
static int rcu_idle_lazy_gp_delay = RCU_IDLE_LAZY_GP_DELAY;
module_param(rcu_idle_lazy_gp_delay, int, 0644);
-extern int tick_nohz_enabled;
-
/*
* Try to advance callbacks for all flavors of RCU on the current CPU.
* Afterwards, if there are any callbacks ready for immediate
invocation,
@@ -1718,7 +1716,7 @@ static void rcu_prepare_for_idle(int cpu)
int tne;
/* Handle nohz enablement switches conservatively. */
-tne = ACCESS_ONCE(tick_nohz_enabled);
+tne = tick_nohz_check();
if (tne != rdtp-tick_nohz_enabled_snap) {
if (rcu_cpu_has_callbacks(cpu, NULL))
invoke_rcu_core(); /* force nohz to see update. */
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3612fc7..d381a22 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -361,7 +361,13 @@ void __init tick_nohz_init(void)
/*
* NO HZ enabled ?
*/
-int tick_nohz_enabled __read_mostly = 1;
+static int tick_nohz_enabled __read_mostly = 1;
+
+int tick_nohz_check(void)
+{
+returntick_nohz_enabled;
+}
+EXPORT_SYMBOL_GPL(tick_nohz_check);
/*
* Enable / Disable tickless mode
--
1.8.4.rc0.1.g8f6a3e5.dirty
--
Best regards
Tianyu Lan
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] libata: avoid waking disk to check power
When a disk is in SLEEP mode it can not respond to commands,
including the CHECK POWER command. Instead of waking up the
sleeping disk, fake the reply to the CHECK POWER command to
indicate the disk is in standby mode. This prevents udisks
from waking up sleeping disks when it polls to see if they
are awake or not before trying to read their smart status.
Signed-off-by: Phillip Susi ps...@ubuntu.com
---
drivers/ata/libata-core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 83b1a9f..573d151 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5084,6 +5084,13 @@ void ata_qc_issue(struct ata_queued_cmd *qc)
/* if device is sleeping, schedule reset and abort the link */
if (unlikely(qc-dev-flags ATA_DFLAG_SLEEPING)) {
+ if (unlikely(qc-tf.command == ATA_CMD_CHK_POWER))
+ {
+ /* fake reply to avoid waking drive */
+ qc-result_tf.nsect = 0;
+ ata_qc_complete(qc);
+ return;
+ }
link-eh_info.action |= ATA_EH_RESET;
ata_ehi_push_desc(link-eh_info, waking up from sleep);
ata_link_abort(link);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH 4/9] block: Make generic_make_request handle arbitrary sized bios
On Mon, Nov 04, 2013 at 03:56:52PM -0800, Mike Christie wrote: On 11/04/2013 03:36 PM, Kent Overstreet wrote: @@ -1822,6 +1820,14 @@ void generic_make_request(struct bio *bio) */ blk_queue_bounce(q, bio); + if (!blk_queue_largebios(q)) + split = blk_bio_segment_split(q, bio, q-bio_split); Is it assumed bios coming down this path are created using bio_add_page? If not, does blk_bio_segment_split need a queue_max_sectors or queue_max_hw_sectors check? I only saw a segment count check below. Shoot, you're absolutely right - thanks, I'll have this fixed in the next version. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for-next] dm: fix missing bi_remaining accounting
On Mon, Nov 04 2013 at 12:49pm -0500, Mikulas Patocka mpato...@redhat.com wrote: On Mon, 4 Nov 2013, Mike Snitzer wrote: On Mon, Nov 04 2013 at 10:25am -0500, Mikulas Patocka mpato...@redhat.com wrote: On Mon, 4 Nov 2013, Mike Snitzer wrote: On Mon, Nov 04 2013 at 10:06am -0500, Mikulas Patocka mpato...@redhat.com wrote: The code uses atomic_inc for restoration of bi_remaining. This patch changes it to atomic_set(1) to avoid an interlocked instruction. In the target's bi_endio routine we are sure that bi_remaining is zero (otherwise, the bi_endio routine wouldn't be called) and there are no concurrent users of the bio, so we can replace atomic_inc with atomic_set(1). This isn't DM-specific. Shouldn't the other places in the tree that use atomic_inc on bi_remaining should really be converted at the same time? There is no 'atomic_inc.*bi_remaining' in other drivers. Wrong. I know btrfs has at least one. As does bcache afaik. grep -r 'atomic_inc.*bi_remaining' * yilds no hits in btrfs or bcache (on git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git , branch remotes/origin/for-next). It only finds drivers/md/dm-cache-target.c, drivers/md/dm-verity.c, drivers/md/dm-snap.c, drivers/md/dm-thin.c. Maybe in other git trees there are more cases of this. Here is the btrfs one I was thinking of from Chris: https://patchwork.kernel.org/patch/3123121/ Should probably make its way into linux-block.git, Jens? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V3 1/2] net: introduce skb_coalesce_rx_frag()
From: Jason Wang jasow...@redhat.com Date: Fri, 1 Nov 2013 14:07:47 +0800 Sometimes we need to coalesce the rx frags to avoid frag list. One example is virtio-net driver which tries to use small frags for both MTU sized packet and GSO packet. So this patch introduce skb_coalesce_rx_frag() to do this. Cc: Rusty Russell ru...@rustcorp.com.au Cc: Michael S. Tsirkin m...@redhat.com Cc: Michael Dalton mwdal...@google.com Cc: Eric Dumazet eduma...@google.com Acked-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Jason Wang jasow...@redhat.com --- Changes from V2: - remove the skb_frag_unref() and let the called to put the page reference Changes from V1: - remove the useless off parameter. Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V3 2/2] virtio-net: coalesce rx frags when possible during rx
From: Jason Wang jasow...@redhat.com Date: Fri, 1 Nov 2013 14:07:48 +0800 Commit 2613af0ed18a11d5c566a81f9a6510b73180660a (virtio_net: migrate mergeable rx buffers to page frag allocators) try to increase the payload/truesize for MTU-sized traffic. But this will introduce the extra overhead for GSO packets received because of the frag list. This commit tries to reduce this issue by coalesce the possible rx frags when possible during rx. Test result shows the about 15% improvement on full size GSO packet receiving (and even better than before commit 2613af0ed18a11d5c566a81f9a6510b73180660a). ... Cc: Rusty Russell ru...@rustcorp.com.au Cc: Michael S. Tsirkin m...@redhat.com Cc: Michael Dalton mwdal...@google.com Cc: Eric Dumazet eduma...@google.com Acked-by: Michael S. Tsirkin m...@redhat.com Acked-by: Eric Dumazet eduma...@google.com Signed-off-by: Jason Wang jasow...@redhat.com --- Changes from V2: - call put_page() instead of depending on skb_coalesce_rx_frag() Looks fantastic, applied, thanks Jason! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
present' made the call to phy_scan optional, if the DT has a link to
the phy node.
However phy_scan has the side effect of calling phy_addr_set, which
writes the phy MDIO address to the ethernet controller. If phy_addr_set
is not called, and the bootloader has not set the correct address then
the driver will fail to function.
Tested on Kirkwood.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 2c210ec..00e43b5 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2890,6 +2890,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
PHY_INTERFACE_MODE_GMII);
if (!mp-phy)
err = -ENODEV;
+ phy_addr_set(mp, mp-phy-addr);
} else if (pd-phy_addr != MV643XX_ETH_PHY_NONE) {
mp-phy = phy_scan(mp, pd-phy_addr);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
Hi Oleg,
On Mon, 4 Nov 2013 15:35:17 +0100, Oleg Nesterov wrote:
Hi Namhyung,
On 11/04, Namhyung Kim wrote:
+ if (atomic_dec_and_test(uprobe_buffer_ref)) {
+ free_percpu(uprobe_cpu_buffer);
+ uprobe_cpu_buffer = NULL;
+ }
+
WARN_ON(!uprobe_filter_is_empty(tu-filter));
Do we really need atomic_t? probe_event_enable/disable is called under
event_mutex and we rely on this fact anyway.
Looking at the code, it seems probe_event_enable/disable() is called
without event_mutex when it called from sys_perf_event_open().
Where?
__ftrace_set_clr_event(), perf_trace_init() or perf_trace_destroy()
hold event_mutex. We rely on this fact anyway.
Ah, you're right. My eyes simply missed it. ;-)
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RFC] vfs: don't revalidate dentries that serve as mountpoints
We had a couple of reports of people that are mounting NFS filesystems,
and then bind mounting certain local files onto dentries in that nfs
mount (sort of like a poor-man's unionmount).
This all works well until the dentry serving as the mountpoint fails
d_revalidate. The dentry will end up being invalidated which makes the
bind mount unreachable via pathwalk.
It doesn't make much sense to me to allow dentries to serve as
mountpoints to end up invalidated, so there's no real point in
attempting to d_revalidate them at all.
Reported-by: Patrick McLean chutz...@gentoo.org
Reported-by: Guang Cheng Li ligua...@cn.ibm.com
Signed-off-by: Jeff Layton jlay...@redhat.com
---
fs/namei.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/namei.c b/fs/namei.c
index caa2805..5b10ad0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -585,6 +585,9 @@ drop_root_mnt:
static inline int d_revalidate(struct dentry *dentry, unsigned int flags)
{
+ /* dentries that serve as mountpoints are always considered valid */
+ if (d_mountpoint(dentry))
+ return 1;
return dentry-d_op-d_revalidate(dentry, flags);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
On Mon, 4 Nov 2013 15:38:13 +0100, Oleg Nesterov wrote: On 11/04, Namhyung Kim wrote: On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote: But. Perhaps it makes sense to at least add a couple of trivial helpers in 10/13? Something like arg_buf_get/put/init, just to simplify the potential changes. Good idea. How about something like below? Thanks, I agree with any implementation ;) static DEFINE_MUTEX(uprobe_buffer_mutex); but see my previous email, afaics we don't need it. I see. Probably checking the event_mutex is locked in front of the _enable/disable function would be enough. Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rcu: Do not trace rcu_is_watching() functions
Paul,
As I added the rcu_is_watching() to the ftrace code to prevent perf
from tracing functions where RCU is not watching, I noticed that the
rcu_is_watching() functions can themselves be traced. I would say this
is a helper function and not something that we need to trace, as it can
cause a slowdown in function tracing (any recursion is detected, so it
only affects performance).
I marked the functions with notrace. You can take this patch and push
it for 3.13 or I can take it if you give me an Acked-by. As it only
affects performance and does not crash the code it's not a must have in
my tree.
If you take it, I can write up a better change log too.
-- Steve
Signed-off-by: Steven Rostedt rost...@goodmis.org
diff --git a/kernel/rcutiny.c b/kernel/rcutiny.c
index 0fa061d..590c8a8 100644
--- a/kernel/rcutiny.c
+++ b/kernel/rcutiny.c
@@ -179,7 +179,7 @@ EXPORT_SYMBOL_GPL(rcu_irq_enter);
/*
* Test whether RCU thinks that the current CPU is idle.
*/
-bool __rcu_is_watching(void)
+bool notrace __rcu_is_watching(void)
{
return rcu_dynticks_nesting;
}
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 981d0c1..499bb2b 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -662,7 +662,7 @@ void rcu_nmi_exit(void)
* rcu_is_watching(), the caller of __rcu_is_watching() must have at
* least disabled preemption.
*/
-bool __rcu_is_watching(void)
+bool notrace __rcu_is_watching(void)
{
return atomic_read(this_cpu_ptr(rcu_dynticks.dynticks)) 0x1;
}
@@ -673,7 +673,7 @@ bool __rcu_is_watching(void)
* If the current CPU is in its idle loop and is neither in an interrupt
* or NMI handler, return true.
*/
-bool rcu_is_watching(void)
+bool notrace rcu_is_watching(void)
{
int ret;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] fs/ext3: use rbtree postorder iteration helper instead of opencoding
On 11/04/2013 04:45 PM, Jan Kara wrote: On Mon 04-11-13 15:26:38, Jan Kara wrote: On Fri 01-11-13 15:38:50, Cody P Schafer wrote: Use rbtree_postorder_for_each_entry_safe() to destroy the rbtree instead of opencoding an alternate postorder iteration that modifies the tree Thanks. I've merged the patch into my tree. Hum, except that the kernel oopses with this patch. And I think the problem is in rbtree_postorder_for_each_entry_safe(). How are those tests for NULL supposed to work? For example if the tree is empty, 'pos' will be NULL and you'll call rb_next_postorder(NULL-field) which is pretty much guaranteed to oops if 'field' doesn't have offset 0 in the structure... You're absolutely right, those NULL checks are wrong when the rb_node isn't the first element. Fix incoming shortly. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] rbtree: fix postorder iteration when the rb_node is not the first element in an entry
Provide a new helper called rb_next_postorder_entry() to perform NULL
checks and container_of() coversions and use it in
rbtree_for_each_entry_safe() to fix oopses that occur when rb_node is
not the first element in the entry.
Additionally, remove the missplaced NULL check from rb_next_postorder().
Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com
---
include/linux/rbtree.h | 20 +++-
lib/rbtree.c | 2 --
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index aa870a4..630eedb 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -86,6 +86,18 @@ static inline void rb_link_node(struct rb_node * node,
struct rb_node * parent,
}
/**
+ * rb_next_postorder_entry - a helper to check for a NULL entry and advance to
+ * the next element.
+ *
+ * @elem: a 'type *' which is contained in an rbtree
+ * @field: the field in 'type' which contains the struct rb_node.
+ */
+#define rb_next_postorder_entry(elem, field) \
+ ((elem) ? rb_entry(rb_next_postorder((elem)-field), \
+ typeof(*(elem)), field) \
+ : NULL)
+
+/**
* rbtree_postorder_for_each_entry_safe - iterate over rb_root in post order of
* given type safe against removal of rb_node entry
*
@@ -96,11 +108,9 @@ static inline void rb_link_node(struct rb_node * node,
struct rb_node * parent,
*/
#define rbtree_postorder_for_each_entry_safe(pos, n, root, field) \
for (pos = rb_entry(rb_first_postorder(root), typeof(*pos), field),\
- n = rb_entry(rb_next_postorder(pos-field), \
- typeof(*pos), field); \
-pos-field; \
+ n = rb_next_postorder_entry(pos, field); \
+pos; \
pos = n, \
- n = rb_entry(rb_next_postorder(pos-field), \
- typeof(*pos), field))
+ n = rb_next_postorder_entry(pos, field))
#endif /* _LINUX_RBTREE_H */
diff --git a/lib/rbtree.c b/lib/rbtree.c
index 65f4eff..08168d0 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -534,8 +534,6 @@ static struct rb_node *rb_left_deepest_node(const struct
rb_node *node)
struct rb_node *rb_next_postorder(const struct rb_node *node)
{
const struct rb_node *parent;
- if (!node)
- return NULL;
parent = rb_parent(node);
/* If we're sitting on node, we've already seen our children */
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] rbtree/test: move rb_node to the middle of the test struct
Avoid making the rb_node the first entry to catch some bugs around NULL
checking the rb_node.
Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com
---
lib/rbtree_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index 31dd4cc..df6c125 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -8,8 +8,8 @@
#define CHECK_LOOPS 100
struct test_node {
- struct rb_node rb;
u32 key;
+ struct rb_node rb;
/* following fields used for testing augmented rbtree functionality */
u32 val;
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t
On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote:
On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote:
On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
Btw., another _really_ interesting comparison would be against
the latest rwsem patches. Mind doing such a comparison?
Sure. Where can I get it? Are they on some git tree?
I've Cc:-ed Tim Chen who might be able to point you to the latest
version.
The last on-lkml submission was in this thread:
Subject: [PATCH v8 0/9] rwsem performance optimizations
Thanks.
I queued bunchs of tests about one hour ago, and already got some
results(If necessary, I can add more data tomorrow when those tests are
finished):
What kind of system are you using to run these workloads on?
I queued jobs on 5 testboxes:
- brickland1: 120 core Ivybridge server
- lkp-ib03: 48 core Ivybridge server
- lkp-sb03: 32 core Sandybridge server
- lkp-nex04: 64 core NHM server
- lkp-a04:Atom server
v3.12-rc7 fe001e3de090e179f95d
-9.3%
brickland1/micro/aim7/shared
+4.3%
lkp-ib03/micro/aim7/fork_test
+2.2%
lkp-ib03/micro/aim7/shared
-2.6% TOTAL
aim7.2000.jobs-per-min
Sorry if I'm missing something, but could you elaborate more on what
these percentages represent?
v3.12-rc7 fe001e3de090e179f95d
-9.3%
brickland1/micro/aim7/shared
-2.6% TOTAL
aim7.2000.jobs-per-min
The comparation base is v3.12-rc7, and we got 9.3 performance regression
at commit fe001e3de090e179f95d, which is the head of rwsem performance
optimizations patch set.
Yunahan, thanks for the data. This I assume is with the entire rwsem
v8 patchset. Any idea of the run variation on the workload?
Tim
brickland1/micro/aim7/shared tells the testbox(brickland1) and testcase:
shared workfile of aim7.
The last line tell what field we are comparing, and it's
aim7.2000.jobs-per-min in this case. 2000 means 2000 users in aim7.
Are they anon vma rwsem + optimistic
spinning patches vs anon vma rwlock?
I tested [PATCH v8 0/9] rwsem performance optimizations only.
Also, I see your running aim7, you might be interested in some of the
results I found when trying out Ingo's rwlock conversion patch on a
largish 80 core system: https://lkml.org/lkml/2013/9/29/280
Besides aim7, I also tested dbench, hackbench, netperf, pigz. And as you
can image and see from the data, aim7 benifit most from the anon_vma
optimization stuff due to high contention of anon_vma lock.
Thanks.
--yliu
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH -tip v2 1/3] kprobes: Introduce nokprobe annotation for non-probe-able functions
(2013/11/01 22:55), Steven Rostedt wrote: On Fri, 01 Nov 2013 11:25:32 + Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote: Instead of __kprobes annotation, introduce 'nokprobe' new annotation to annotate that the function is not probed by kprobes. Previously the '__kprobes' is used just for avoiding probes on kprobes-related functions which will be used from kprobes. However nowadays we use it for prohibiting probing the functions implicitly invoked from kprobes int3 handler, since that causes infinit-loop lockup or sudden reboot. In this case, the annotated functions are not limited in the kprobes-related functions, and __kprobes looks very confusing. (Moreover, actually, most of control-side kprobes functions like as register_kprobes() are safely probed by kprobes) Thus, we decide to introduce 'nokprobe' new annotation. We leave __kprobes just for compatibility but it should be replaced or removed eventually. New commits must use 'nokprobe' for this purpose. Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Cc: Ingo Molnar mi...@kernel.org Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com Cc: David S. Miller da...@davemloft.net --- include/linux/compiler.h |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 92669cd..173c64e 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -353,8 +353,10 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect); /* Ignore/forbid kprobes attach on very low level functions marked by this attribute: */ #ifdef CONFIG_KPROBES -# define __kprobes __attribute__((__section__(.kprobes.text))) +# define nokprobe __attribute__((__section__(.kprobes.text))) I wonder if we should have both a __kprobes and nokprobe annotation, such that we have: # define __kprobes__attribute__((__section__(.kprobes.text))) # define nokprobe __attribute__((__section__(.nokprobes.text))) Then use __kprobes for the actual kprobes code, and nokprobe for all the places that must not be traced by kprobes. No, actually, we don't need __kprobes anymore. That has started historically by misunderstanding the problem. kprobes is using the .kprobes.text only for blacklisting the non probe-able functions. Thus, eventually it should be renamed .nokprobe.text, not be added. It just seems strange to me grouping kprobes code with non kprobes code. Yeah, so I'd like to cleanup all the __kprobes finally (and classify which is not needed). Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
On 11/04, Namhyung Kim wrote:
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
This does not look right to me.
- get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
-i_mmap_mutex.
Hmm.. yes, I think this is not needed. I guess it should lookup a
proper vma in current-mm with mmap_sem read-locked.
- this only allows to read the data from the same binary.
Right. This is also an unnecessary restriction. We should be able to
access data in other binary.
Yes... but this needs another discussion. In general, we simply can not
do this with the suggested syntax.
Agreed.
Say you want to probe this foo binary and dump stdin from libc.so.
You can't do this. You simply can't know where libc.so will be mmaped.
But: if we attach the event to the already running process, or if we
disable the randomization, then we can probably do this, see below.
Or the syntax should be name=probe @file/addr or something like this.
Okay. Let's call this kind of thing cross-fetch (or a better name can
be suggested). This is more complex situation and needs more discussion
as you said. So let's skip the discussion for now. :)
- in particular, you can't read the data from bss
I can't understand why.. The bss region should also be in a same vma of
normal data, no?
No, no. bss is mmaped anonymously, at least in general. See set_brk() in
load_elf().
Ah, thanks for the pointer. I also need to say that I'm not familiar
with the code base.
Looking at the code, it seems to add a anon mapping iff the bss region
spans on two or more pages - that's why I missed it from my simple
test. :/
I thought the gcc somehow aligns data to next page boundary.
And perhaps it even should, my system is old. But this doesn't really
matter, the process itself can create another mapping.
Right.
But if
it's not the case, we need to recognize which is the proper one..
Simply preferring a writable vma to a read-only vma is what's came to my
head now. Do you have an idea?
So far I think that trace_uprobes.c should not play games with vma. At all.
Yes, playing with vma is fragile. But otherwise how can we get the
address from the file+offset in random processes?
---
Can't we simply implement get_user_vaddr() as
static void __user *get_user_vaddr(unsigned long addr, struct
trace_uprobe *tu)
{
void __user *vaddr = (void __force __user *)addr;
/* A NULL tu means that we already got the vaddr */
if (tu)
vaddr += (current-mm-start_data PAGE_MASK);
return vaddr;
}
?
I did this change, and now the test-case above works. And it also works
with cc -pie -fPIC,
# nm foo | grep -w global
00200c9c D global
# perf probe -x ./foo -a func var=@0xc9c:u32
# perf record -e probe_foo:func ./foo
...
# perf script | tail -1
foo 576 [001] 475.519940: probe_foo:func: (7ffe95ca3814)
var=4321
What do you think?
This can only work with the probes fetching data from the executable,
right? But as I said it should support any other binaries too.
See above, we can't in general read other binaries.
Okay, I need to clarify my words. I'm not saying about cross-fetch
here, what I wanted to say is adding a probe in some dso and fetch data
from the dso.
Primary usecase I have in mind is supporting SDTs in the perf probe
tool. Currently many libraries including glibc add tracepoints (SDTs)
within themselves to be traced/profilied easily.
You can see Hemant's work on this here:
https://lkml.org/lkml/2013/10/18/274
But: if we know know where it is mmapped we can do this, just we need
to calculate the right addr passed to trace_uprobes.
Or: we should support both absolute and relative addresses, this is what
I was going to discuss later.
But I guess this specifying address directly is hard to apply to
multiple processes - like system-wide tracing in perf.
static void __user *get_user_vaddr(unsigned long addr, struct trace_uprobe
*tu)
{
unsigned long pgoff = addr PAGE_SHIFT;
struct vm_area_struct *vma, *orig_vma = NULL;
unsigned long vaddr = 0;
if (tu == NULL) {
/* A NULL tu means that we already got the vaddr */
return (void __force __user *) addr;
}
down_read(current-mm-mmap_sem);
vma = current-mm-mmap;
Cough, it can be null if another thread does munmap(0, TASK_SIZE) ;)
But this doesn't matter.
:)
do {
if (!vma-vm_file || vma-vm_file-f_inode != tu-inode) {
/*
* We found read-only mapping for this inode.
* (provided that all mappings for this inode
* have consecutive addresses)
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 16:51:31 +0100, Oleg Nesterov wrote: On 11/04, Namhyung Kim wrote: On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote: On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote: - this only allows to read the data from the same binary. Right. This is also an unnecessary restriction. We should be able to access data in other binary. Hmm.. I guess this gonna be not simple Yes ;) - perhaps it can only be supported for per-process uprobe with known virtual addresses? Known is very limited. Even in the simplest case (like your test-case from from 0/13), you simply can't know the address of int glob if you compile it with -pie -fPIC. As for other binaries (say libc) the problem is even worse, and randomize_va_space adds even more pain. Hmm.. right. We should deal with relative addresses from the base mapping address of a binary. But in any case, I strongly believe that it doesn't make any sense to rely on tu-inode in get_user_vaddr(). I'll think about it more. Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and kernel will
reboot.
This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Borislav Petkov b...@suse.de
Cc: Ingo Molnar mi...@kernel.org
---
kernel/extable.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/extable.c b/kernel/extable.c
index 832cb28..022fb25 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
* pointer is part of the kernel text, we need to do some
* special dereferencing first.
*/
-int func_ptr_is_kernel_text(void *ptr)
+int nokprobe func_ptr_is_kernel_text(void *ptr)
{
unsigned long addr;
addr = (unsigned long) dereference_function_descriptor(ptr);
One thing I worry about the nokprobe annotation, is that it moves the
location of the function out of local. This function no exists in
the section with its users. Same with the debug functions in the
other patch.
Now these may be a slow path where we really don't care, but if the
nokprobe expands this can cause issues.
The nokprobe works differently than notrace as notrace is just an
attribute that tells gcc not to add mcount to it. The nokprobe
actually moves the function into a different section.
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t
On Mon, 2013-11-04 at 17:44 -0800, Tim Chen wrote:
On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote:
On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote:
On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
Btw., another _really_ interesting comparison would be against
the latest rwsem patches. Mind doing such a comparison?
Sure. Where can I get it? Are they on some git tree?
I've Cc:-ed Tim Chen who might be able to point you to the latest
version.
The last on-lkml submission was in this thread:
Subject: [PATCH v8 0/9] rwsem performance optimizations
Thanks.
I queued bunchs of tests about one hour ago, and already got some
results(If necessary, I can add more data tomorrow when those tests are
finished):
What kind of system are you using to run these workloads on?
I queued jobs on 5 testboxes:
- brickland1: 120 core Ivybridge server
- lkp-ib03: 48 core Ivybridge server
- lkp-sb03: 32 core Sandybridge server
- lkp-nex04: 64 core NHM server
- lkp-a04:Atom server
v3.12-rc7 fe001e3de090e179f95d
-9.3%
brickland1/micro/aim7/shared
+4.3%
lkp-ib03/micro/aim7/fork_test
+2.2%
lkp-ib03/micro/aim7/shared
-2.6% TOTAL
aim7.2000.jobs-per-min
Sorry if I'm missing something, but could you elaborate more on what
these percentages represent?
v3.12-rc7 fe001e3de090e179f95d
-9.3%
brickland1/micro/aim7/shared
-2.6% TOTAL
aim7.2000.jobs-per-min
The comparation base is v3.12-rc7, and we got 9.3 performance regression
at commit fe001e3de090e179f95d, which is the head of rwsem performance
optimizations patch set.
Yunahan, thanks for the data. This I assume is with the entire rwsem
v8 patchset. Any idea of the run variation on the workload?
Yunhan,
I haven't got a chance to make multiple runs to check the standard
deviation. From the few runs I did, I got a 5.1% increase in
performance for aim7 shared workload for the complete rwsem patchset
on a similar machine that you are using. The patches are applied
to the 3.12-rc7 and compared to the vanilla kernel.
Thanks.
Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling in-memory write cache for x86-64 in Linux II
On Tue, 5 Nov 2013 09:40:55 +0800 Figo.zhang figo1...@gmail.com wrote: Of course, if you don't use Linux on the desktop you don't really care - well, I do. Also not everyone in this world has an UPS - which means such a huge buffer can lead to a serious data loss in case of a power blackout. I don't have a desk (just a lap), but I use Linux on all my computers and I've never really noticed the problem. Maybe I'm just very patient, or maybe I don't work with large data sets and slow devices. However I don't think data-loss is really a related issue. Any process that cares about data safety *must* use fsync at appropriate places. This has always been true. =May i ask question that, some like ext4 filesystem, if some app motify the files, it create some dirty data. if some meta-data writing to the journal disk when a power backout, it will be lose some serious data and the the file will damage? If you modify a file, then you must take care that you can recover from a crash at any point in the process. If the file is small, the usual approach is to create a copy of the file with the appropriate changes made, then 'fsync' the file and rename the new file over the old file. If the file is large you might need some sort of update log (in a small file) so you can replay recent updates after a crash. The journalling that the filesystem provides only protects the filesystem metadata. It does not protect the consistency of the data in your file. I hope that helps. NeilBrown signature.asc Description: PGP signature
[PATCHSET driver-core-next] kernfs: implement trusted.* xattr support
Hello, (This is for 3.14-rc1. Posting early for review. Will refresh and repost once the next driver-core-next opens.) kernfs inherited security.* xattr support from sysfs but for it to be useable for cgroupfs, it needs to support trusted.* too. This patchset adds trusted.* xattr support using simple_xattr*(). Note that the existing security.* support is gimped in that it doesn't include remove/get/list. This patchset implements all operations for trusted.* but doesn't change security.* support. David P. Quigley, can you please comment on this? It doesn't seem like adding it would be too difficult. Why don't we have it yet? Are they unnecessary? This patchset contains the following two patches. 0001-kernfs-update-sysfs_init_inode_attrs.patch 0002-kernfs-implement-trusted.-xattr-support.patch 0001 preps and 0002 implements. This patchset is on top of driver-core-next 0cae60f91494 (sysfs: rename sysfs_assoc_lock and explain what it's about) + [1] [PATCHSET] sysfs: separate out kernfs, take #2 and available in the following git branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-kernfs-xattr diffstat follows. Thanks. fs/kernfs/dir.c | 12 +++- fs/kernfs/inode.c | 123 fs/kernfs/kernfs-internal.h | 13 +++- fs/kernfs/symlink.c |3 + 4 files changed, 103 insertions(+), 48 deletions(-) -- tejun [1] https://lkml.kernel.org/g/1383472398-17812-1-git-send-email...@kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] kernfs: update sysfs_init_inode_attrs()
sysfs_init_inode_attrs() is a bit clumsy to use requiring the caller
to check whether @sd-s_iattr is already set or not. Rename it to
sysfs_inode_attrs(), update it to check whether @sd-s_iattr is
already initialized before trying to initialize it and return
@sd-s_iattr. This simplifies the callers.
While at it,
* Rename struct sysfs_inode_attrs pointer variables to attrs. As
kernfs no longer deals with struct attribute, this isn't confusing
and makes it easier to distinguish from struct iattr pointers.
* A new field will be added to sysfs_inode_attrs. Reindent in
preparation.
This patch doesn't introduce any behavior changes.
Signed-off-by: Tejun Heo t...@kernel.org
---
fs/kernfs/inode.c | 60 -
fs/kernfs/kernfs-internal.h | 6 ++---
2 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index b4cae6f..a1f8382 100644
--- a/fs/kernfs/inode.c
+++ b/fs/kernfs/inode.c
@@ -43,15 +43,17 @@ void __init sysfs_inode_init(void)
panic(failed to init sysfs_backing_dev_info);
}
-static struct sysfs_inode_attrs *sysfs_init_inode_attrs(struct sysfs_dirent
*sd)
+static struct sysfs_inode_attrs *sysfs_inode_attrs(struct sysfs_dirent *sd)
{
- struct sysfs_inode_attrs *attrs;
struct iattr *iattrs;
- attrs = kzalloc(sizeof(struct sysfs_inode_attrs), GFP_KERNEL);
- if (!attrs)
+ if (sd-s_iattr)
+ return sd-s_iattr;
+
+ sd-s_iattr = kzalloc(sizeof(struct sysfs_inode_attrs), GFP_KERNEL);
+ if (!sd-s_iattr)
return NULL;
- iattrs = attrs-ia_iattr;
+ iattrs = sd-s_iattr-ia_iattr;
/* assign default attributes */
iattrs-ia_mode = sd-s_mode;
@@ -59,26 +61,20 @@ static struct sysfs_inode_attrs
*sysfs_init_inode_attrs(struct sysfs_dirent *sd)
iattrs-ia_gid = GLOBAL_ROOT_GID;
iattrs-ia_atime = iattrs-ia_mtime = iattrs-ia_ctime = CURRENT_TIME;
- return attrs;
+ return sd-s_iattr;
}
static int __kernfs_setattr(struct sysfs_dirent *sd, const struct iattr *iattr)
{
- struct sysfs_inode_attrs *sd_attrs;
+ struct sysfs_inode_attrs *attrs;
struct iattr *iattrs;
unsigned int ia_valid = iattr-ia_valid;
- sd_attrs = sd-s_iattr;
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+ return -ENOMEM;
- if (!sd_attrs) {
- /* setting attributes for the first time, allocate now */
- sd_attrs = sysfs_init_inode_attrs(sd);
- if (!sd_attrs)
- return -ENOMEM;
- sd-s_iattr = sd_attrs;
- }
- /* attributes were changed at least once in past */
- iattrs = sd_attrs-ia_iattr;
+ iattrs = attrs-ia_iattr;
if (ia_valid ATTR_UID)
iattrs-ia_uid = iattr-ia_uid;
@@ -143,22 +139,19 @@ out:
static int sysfs_sd_setsecdata(struct sysfs_dirent *sd, void **secdata,
u32 *secdata_len)
{
- struct sysfs_inode_attrs *iattrs;
+ struct sysfs_inode_attrs *attrs;
void *old_secdata;
size_t old_secdata_len;
- if (!sd-s_iattr) {
- sd-s_iattr = sysfs_init_inode_attrs(sd);
- if (!sd-s_iattr)
- return -ENOMEM;
- }
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+ return -ENOMEM;
- iattrs = sd-s_iattr;
- old_secdata = iattrs-ia_secdata;
- old_secdata_len = iattrs-ia_secdata_len;
+ old_secdata = attrs-ia_secdata;
+ old_secdata_len = attrs-ia_secdata_len;
- iattrs-ia_secdata = *secdata;
- iattrs-ia_secdata_len = *secdata_len;
+ attrs-ia_secdata = *secdata;
+ attrs-ia_secdata_len = *secdata_len;
*secdata = old_secdata;
*secdata_len = old_secdata_len;
@@ -216,17 +209,16 @@ static inline void set_inode_attr(struct inode *inode,
struct iattr *iattr)
static void sysfs_refresh_inode(struct sysfs_dirent *sd, struct inode *inode)
{
- struct sysfs_inode_attrs *iattrs = sd-s_iattr;
+ struct sysfs_inode_attrs *attrs = sd-s_iattr;
inode-i_mode = sd-s_mode;
- if (iattrs) {
+ if (attrs) {
/* sysfs_dirent has non-default attributes
* get them from persistent copy in sysfs_dirent
*/
- set_inode_attr(inode, iattrs-ia_iattr);
- security_inode_notifysecctx(inode,
- iattrs-ia_secdata,
- iattrs-ia_secdata_len);
+ set_inode_attr(inode, attrs-ia_iattr);
+ security_inode_notifysecctx(inode, attrs-ia_secdata,
+ attrs-ia_secdata_len);
}
if (sysfs_type(sd) == SYSFS_DIR)
diff --git a/fs/kernfs/kernfs-internal.h b/fs/kernfs/kernfs-internal.h
index
[PATCH 2/2] kernfs: implement trusted.* xattr support
kernfs inherited security.* xattr support from sysfs. This patch
extends xattr support to trusted.* using simple_xattr_*(). As
trusted xattrs are restricted to CAP_SYS_ADMIN, simple_xattr_*() which
uses kernel memory for storage shouldn't be problematic.
Note that the existing security.* support doesn't implement
get/remove/list and the this patch only implements those ops for
trusted.*. We probably want to extend those ops to include support
for security.*.
This patch will allow using kernfs from cgroup which requires
trusted.* xattr support.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: David P. Quigley dpqu...@tycho.nsa.gov
---
fs/kernfs/dir.c | 12 ++---
fs/kernfs/inode.c | 63 +++--
fs/kernfs/kernfs-internal.h | 7 +
fs/kernfs/symlink.c | 3 +++
4 files changed, 74 insertions(+), 11 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 6db5ed3..d5b33fe 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -255,9 +255,12 @@ void kernfs_put(struct sysfs_dirent *sd)
kernfs_put(sd-s_symlink.target_sd);
if (sysfs_type(sd) SYSFS_COPY_NAME)
kfree(sd-s_name);
- if (sd-s_iattr sd-s_iattr-ia_secdata)
- security_release_secctx(sd-s_iattr-ia_secdata,
- sd-s_iattr-ia_secdata_len);
+ if (sd-s_iattr) {
+ if (sd-s_iattr-ia_secdata)
+ security_release_secctx(sd-s_iattr-ia_secdata,
+ sd-s_iattr-ia_secdata_len);
+ simple_xattrs_free(sd-s_iattr-xattrs);
+ }
kfree(sd-s_iattr);
ida_simple_remove(root-ino_ida, sd-s_ino);
kmem_cache_free(sysfs_dir_cachep, sd);
@@ -711,6 +714,9 @@ const struct inode_operations sysfs_dir_inode_operations = {
.setattr= sysfs_setattr,
.getattr= sysfs_getattr,
.setxattr = sysfs_setxattr,
+ .removexattr= sysfs_removexattr,
+ .getxattr = sysfs_getxattr,
+ .listxattr = sysfs_listxattr,
};
static struct sysfs_dirent *sysfs_leftmost_descendant(struct sysfs_dirent *pos)
diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index a1f8382..18ad431 100644
--- a/fs/kernfs/inode.c
+++ b/fs/kernfs/inode.c
@@ -35,6 +35,9 @@ static const struct inode_operations sysfs_inode_operations =
{
.setattr= sysfs_setattr,
.getattr= sysfs_getattr,
.setxattr = sysfs_setxattr,
+ .removexattr= sysfs_removexattr,
+ .getxattr = sysfs_getxattr,
+ .listxattr = sysfs_listxattr,
};
void __init sysfs_inode_init(void)
@@ -61,6 +64,8 @@ static struct sysfs_inode_attrs *sysfs_inode_attrs(struct
sysfs_dirent *sd)
iattrs-ia_gid = GLOBAL_ROOT_GID;
iattrs-ia_atime = iattrs-ia_mtime = iattrs-ia_ctime = CURRENT_TIME;
+ simple_xattrs_init(sd-s_iattr-xattrs);
+
return sd-s_iattr;
}
@@ -162,23 +167,25 @@ int sysfs_setxattr(struct dentry *dentry, const char
*name, const void *value,
size_t size, int flags)
{
struct sysfs_dirent *sd = dentry-d_fsdata;
+ struct sysfs_inode_attrs *attrs;
void *secdata;
int error;
u32 secdata_len = 0;
- if (!sd)
- return -EINVAL;
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+ return -ENOMEM;
if (!strncmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN)) {
const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
error = security_inode_setsecurity(dentry-d_inode, suffix,
value, size, flags);
if (error)
- goto out;
+ return error;
error = security_inode_getsecctx(dentry-d_inode,
secdata, secdata_len);
if (error)
- goto out;
+ return error;
mutex_lock(sysfs_mutex);
error = sysfs_sd_setsecdata(sd, secdata, secdata_len);
@@ -186,10 +193,50 @@ int sysfs_setxattr(struct dentry *dentry, const char
*name, const void *value,
if (secdata)
security_release_secctx(secdata, secdata_len);
- } else
- return -EINVAL;
-out:
- return error;
+ return error;
+ } else if (!strncmp(name, XATTR_TRUSTED_PREFIX,
XATTR_TRUSTED_PREFIX_LEN)) {
+ return simple_xattr_set(attrs-xattrs, name, value, size,
+ flags);
+ }
+
+ return -EINVAL;
+}
+
+int sysfs_removexattr(struct dentry *dentry, const char *name)
+{
+ struct sysfs_dirent *sd = dentry-d_fsdata;
+ struct sysfs_inode_attrs *attrs;
+
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+
Re: [PATCH 11/13] tracing/kprobes: Add priv argument to fetch functions
On Mon, 4 Nov 2013 17:09:14 +0100, Oleg Nesterov wrote:
See my replies to 0/13. Lets assume that you agree that get_user_vaddr()
doesn't need tu-inode.
Okay.
On 10/29, Namhyung Kim wrote:
This argument is for passing private data structure to each fetch
function and will be used by uprobes.
In this case, why do we need this void *priv? It actually becomes
bool need_addr_translation.
Right. I added it because the deref method is used for both of kprobes
and uprobes and it only needed for uprobes. And I thought if we need
something for kprobes later, it can be reused so make it general.
Can't we avoid it? Can't we just add FETCH_MTD_memory_notranslate ?
kprobes should use the same methods for FETCH_MTD_memory*, uprobes
should obviously adjust the addr in FETCH_MTD_memory.
Then (afaics) we need a single change in parse_probe_arg(),
- dprm-fetch = t-fetch[FETCH_MTD_memory];
+ dprm-fetch = t-fetch[FETCH_MTD_memory_notranslate];
Yes, this will blow *probes_fetch_type_table[], but looks simpler.
Looks good to me too, thanks! :)
And. This way it would be simple to teach parse_probe_arg('@') to use
_notranslate, say, @=addr or whatever.
Yeah, it'll be useful at least for fetching data in anon pages.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote: On 11/04, Oleg Nesterov wrote: But in any case, I strongly believe that it doesn't make any sense to rely on tu-inode in get_user_vaddr(). Hmm. But I forgot about the case when you probe the function in libc and want to dump the variable in libc... Right. Actually that's what I really wanted. So probably I was wrong and this all needs more thinking. Damn. :) Perhaps we really need to pass @file/offset, but it is not clear what we can do with bss/anon-mapping. The @file/offset should work with bss since data in bss is accessed via an offset in the program, but still anon-mapping has nothing to do with it. Hmm... Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/13] tracing/uprobes: Add more fetch functions
On Mon, 4 Nov 2013 17:44:31 +0100, Oleg Nesterov wrote:
On 11/04, Namhyung Kim wrote:
On Thu, 31 Oct 2013 19:22:18 +0100, Oleg Nesterov wrote:
On 10/29, Namhyung Kim wrote:
+static void __user *get_user_vaddr(unsigned long addr, struct
trace_uprobe *tu)
+{
+ unsigned long pgoff = addr PAGE_SHIFT;
+ struct vm_area_struct *vma;
+ struct address_space *mapping;
+ unsigned long vaddr = 0;
+
+ if (tu == NULL) {
+ /* A NULL tu means that we already got the vaddr */
+ return (void __force __user *) addr;
+ }
+
+ mapping = tu-inode-i_mapping;
+
+ mutex_lock(mapping-i_mmap_mutex);
+ vma_interval_tree_foreach(vma, mapping-i_mmap, pgoff, pgoff) {
+ if (vma-vm_mm != current-mm)
+ continue;
+ if (!(vma-vm_flags VM_READ))
+ continue;
+
+ vaddr = offset_to_vaddr(vma, addr);
+ break;
+ }
+ mutex_unlock(mapping-i_mmap_mutex);
+
+ WARN_ON_ONCE(vaddr == 0);
Hmm. But unless I missed something this addr passed as an argument can
be wrong? And if nothing else this or another thread can unmap the vma?
You mean WARN_ON_ONCE here is superfluous? I admit that it should
protect concurrent vma [un]mappings. Please see my reply in other
thread for a new approach.
Whatever we do this address can be unmapped. For example, just because of
@invalid_address passed to trace_uprobe.c.
We do not really care, copy_from_user() should fail. But we should not
WARN() in this case.
Okay, I see. Will remove it in the next spin.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/13] tracing/uprobes: Add more fetch functions
Hi Steve,
On Mon, 4 Nov 2013 12:17:06 -0500, Steven Rostedt wrote:
On Mon, 4 Nov 2013 17:44:31 +0100
Oleg Nesterov o...@redhat.com wrote:
On 11/04, Namhyung Kim wrote:
On Thu, 31 Oct 2013 19:22:18 +0100, Oleg Nesterov wrote:
On 10/29, Namhyung Kim wrote:
+static void __user *get_user_vaddr(unsigned long addr, struct
trace_uprobe *tu)
+{
+ unsigned long pgoff = addr PAGE_SHIFT;
+ struct vm_area_struct *vma;
+ struct address_space *mapping;
+ unsigned long vaddr = 0;
+
+ if (tu == NULL) {
+ /* A NULL tu means that we already got the vaddr */
+ return (void __force __user *) addr;
+ }
+
+ mapping = tu-inode-i_mapping;
+
+ mutex_lock(mapping-i_mmap_mutex);
+ vma_interval_tree_foreach(vma, mapping-i_mmap, pgoff, pgoff) {
+ if (vma-vm_mm != current-mm)
+ continue;
+ if (!(vma-vm_flags VM_READ))
+ continue;
+
+ vaddr = offset_to_vaddr(vma, addr);
+ break;
+ }
+ mutex_unlock(mapping-i_mmap_mutex);
+
+ WARN_ON_ONCE(vaddr == 0);
Hmm. But unless I missed something this addr passed as an argument can
be wrong? And if nothing else this or another thread can unmap the vma?
You mean WARN_ON_ONCE here is superfluous? I admit that it should
protect concurrent vma [un]mappings. Please see my reply in other
thread for a new approach.
Whatever we do this address can be unmapped. For example, just because of
@invalid_address passed to trace_uprobe.c.
We do not really care, copy_from_user() should fail. But we should not
WARN() in this case.
I agree, the WARN_ON_ONCE() above looks like it's uncalled for.
WARN()ings should only be used when an anomaly in the kernel logic is
detected. Can this trigger on bad input from user space, or something
else that userspace does? (a race with unmapping memory?). If so, error
out to the user process, but do not call any of the WARN() functions.
Will do. Thanks for the explanation.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] libata: use sleep instead of standby command
+linux-ide On 11/05/2013 08:52 AM, Phillip Susi wrote: The ATA SLEEP mode saves some more power than SUSPEND, and has basically the same recovery time, so use it instead. I suppose this is mainly for runtime PM? Since for system suspend/hibernation, the disk and its controller will be powered off anyway. Best regards, Aaron Signed-off-by: Phillip Susi ps...@ubuntu.com --- drivers/ata/libata-scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 97a0cef..79b75fd 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1362,8 +1362,8 @@ static unsigned int ata_scsi_start_stop_xlat(struct ata_queued_cmd *qc) system_entering_hibernation()) goto skip; - /* Issue ATA STANDBY IMMEDIATE command */ - tf-command = ATA_CMD_STANDBYNOW1; + /* Issue ATA SLEEP command */ + tf-command = ATA_CMD_SLEEP; } /* -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On 11/05/2013 05:54 AM, Joe Perches wrote:
Add this to try this...
Chen Gang's defect is because his git repository branch
had a commit he authored but where did not add his signature.
Hmm... for pure next-20131101 tree in my git directory and the demo
patches in attachment, it will cause this issue.
And excuse me, I am not quite familiar with git, could you provide more
details (e.g. where the special difference of the demo patches or the
pure next-20131101 tree in my git directory)? thanks.
Also, there's a defect in function vcs_find_signers.
It should only return the commit count and array references.
If there are no signers in the commit history interval specified,
then the authors array is added to the signers array and
returned as a single array.
Use references instead.
Make sure that references are defined in the places
that vcs_find_signers is called.
After apply the patch below, it can work well.
Tested-by Chen Gang gang.c...@asianux.com
Signed-off-by: Joe Perches j...@perches.com
---
scripts/get_maintainer.pl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ee9adb8..9c3986f 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -128,7 +128,7 @@ my %VCS_cmds_git = (
blame_commit_pattern = ^([0-9a-f]+) ,
author_pattern = ^GitAuthor: (.*),
subject_pattern = ^GitSubject: (.*),
-stat_pattern = (\\d+)\\t(\\d+)\\t\$file,
+stat_pattern = ^(\\d+)\\t(\\d+)\\t\$file\$,
);
my %VCS_cmds_hg = (
@@ -156,7 +156,7 @@ my %VCS_cmds_hg = (
blame_commit_pattern = ^([ 0-9a-f]+):,
author_pattern = ^HgAuthor: (.*),
subject_pattern = ^HgSubject: (.*),
-stat_pattern = (\\d+)\t(\\d+)\t\$file,
+stat_pattern = ^(\\d+)\t(\\d+)\t\$file\$,
);
my $conf = which_conf(.get_maintainer.conf);
@@ -1297,7 +1297,7 @@ sub vcs_find_signers {
#print(stats: @stats\n);
-return (0, @signatures, @authors) if !@signatures;
+return (0, \@signatures, \@authors, \@stats) if !@signatures;
save_commits_by_author(@lines) if ($interactive);
save_commits_by_signer(@lines) if ($interactive);
@@ -1880,9 +1880,10 @@ sub vcs_file_signoffs {
$cmd =~ s/(\$\w+)/$1/eeg;# interpolate $cmd
($commits, $signers_ref, $authors_ref, $stats_ref) =
vcs_find_signers($cmd, $file);
-@signers = @{$signers_ref};
-@authors = @{$authors_ref};
-@stats = @{$stats_ref};
+
+@signers = @{$signers_ref} if defined $signers_ref;
+@authors = @{$authors_ref} if defined $authors_ref;
+@stats = @{$stats_ref} if defined $stats_ref;
#print(commits: $commits\nsigners:@signers\nauthors:
@authors\nstats: @stats\n);
@@ -1965,8 +1966,8 @@ sub vcs_file_blame {
$cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
($commit_count, $commit_signers_ref, $commit_authors_ref,
$stats_ref) = vcs_find_signers($cmd, $file);
- @commit_authors = @{$commit_authors_ref};
- @commit_signers = @{$commit_signers_ref};
+ @commit_authors = @{$commit_authors_ref} if defined
$commit_authors_ref;
+ @commit_signers = @{$commit_signers_ref} if defined
$commit_signers_ref;
push(@signers, @commit_signers);
} else {
@@ -1983,8 +1984,8 @@ sub vcs_file_blame {
$cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
($commit_count, $commit_signers_ref, $commit_authors_ref,
$stats_ref) = vcs_find_signers($cmd, $file);
- @commit_authors = @{$commit_authors_ref};
- @commit_signers = @{$commit_signers_ref};
+ @commit_authors = @{$commit_authors_ref} if defined
$commit_authors_ref;
+ @commit_signers = @{$commit_signers_ref} if defined
$commit_signers_ref;
push(@signers, @commit_signers);
}
--
Chen Gang
Subject: [PATCH] hexagon: kernel: remove useless variables 'dn', 'r' and 'err' in time_init_deferred() in time.c
Date: Fri, 01 Nov 2013 19:07:48 +0800
From: Chen Gang gang.c...@asianux.com
Remove them, since they are useless. The related warnings (with
allmodconfig for v4):
CC arch/hexagon/kernel/time.o
arch/hexagon/kernel/time.c: In function 'time_init_deferred':
arch/hexagon/kernel/time.c:196: warning: unused variable 'err'
arch/hexagon/kernel/time.c:195: warning: unused variable 'r'
arch/hexagon/kernel/time.c:194: warning: unused variable 'dn'
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/hexagon/kernel/time.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/hexagon/kernel/time.c b/arch/hexagon/kernel/time.c
index 9903fad..d0c4f5a 100644
--- a/arch/hexagon/kernel/time.c
+++ b/arch/hexagon/kernel/time.c
@@ -191,9 +191,6 @@ void __init time_init_deferred(void)
{
struct resource *resource =
Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
Hi Vinod Koul and Dan Williams,
Ping?
On 10/17/2013 01:56 PM, Hongbo Zhang wrote:
Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds support to 8-channel DMA engine, thus the driver
works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
drivers/dma/Kconfig |9 +
drivers/dma/fsldma.c |9 ++---
drivers/dma/fsldma.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
-tristate Freescale Elo and Elo Plus DMA support
+tristate Freescale Elo series DMA support
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA
controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and
the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx
parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3
is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate Freescale MPC512x built-in DMA engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
fsldma_device *fdev,
WARN_ON(fdev-feature != chan-feature);
chan-dev = fdev-dev;
-chan-id = ((res.start - 0x100) 0xfff) 7;
+chan-id = (res.start 0xfff) 0x300 ?
+ ((res.start - 0x100) 0xfff) 7 :
+ ((res.start - 0x200) 0xfff) 7;
if (chan-id = FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev-dev, too many channels for device\n);
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct
platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+{ .compatible = fsl,elo3-dma, },
{ .compatible = fsl,eloplus-dma, },
{ .compatible = fsl,elo-dma, },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
-pr_info(Freescale Elo / Elo Plus DMA driver\n);
+pr_info(Freescale Elo series DMA driver\n);
return platform_driver_register(fsldma_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION(Freescale Elo / Elo Plus DMA driver);
+MODULE_DESCRIPTION(Freescale Elo series DMA driver);
MODULE_LICENSE(GPL);
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs;/* DGSR register base */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG][ext2] XIP does not work on ext2
Hi Jan,
On Mon, Nov 4, 2013 at 4:37 PM, Jan Kara j...@suse.cz wrote:
Hello,
On Mon 04-11-13 14:31:34, Andiry Xu wrote:
When I'm trying XIP on ext2, I find that xip does not work on ext2
with latest kernel.
Reproduce steps:
Compile kernel with following configs:
CONFIG_BLK_DEV_XIP=y
CONFIG_EXT2_FS_XIP=y
And run following commands:
# mke2fs -b 4096 /dev/ram0
# mount -t ext2 -o xip /dev/ram0 /mnt/ramdisk/
# dd if=/dev/zero of=/mnt/ramdisk/test1 bs=1M count=16
And it shows:
dd: writing `/mnt/ramdisk/test1': No space left on device
df also shows /mnt/ramdisk is 100% full. Its default size is 64MB so a
16MB write should only occupy 1/4 capacity.
Criminal commit:
After git bisect, it points to the following commit:
8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b
Ext2: mark inode dirty after the function dquot_free_block_nodirty is called
Thanks for report and the bisection!
Particularly, the following code:
@@ -1412,9 +1415,11 @@ allocated:
*errp = 0;
brelse(bitmap_bh);
-dquot_free_block_nodirty(inode, *count-num);
-mark_inode_dirty(inode);
-*count = num;
+if (num *count) {
+dquot_free_block_nodirty(inode, *count-num);
+mark_inode_dirty(inode);
+*count = num;
+}
return ret_block;
Not mark_inode_dirty() is called only when num is less than *count.
However, I've seen
with the dd command, there is case where num = *count.
Fix:
I've verified that the following patch fixes the issue:
diff --git a/fs/ext2/balloc.c b/fs/ext2/balloc.c
index 9f9992b..5446a52 100644
--- a/fs/ext2/balloc.c
+++ b/fs/ext2/balloc.c
@@ -1406,11 +1406,10 @@ allocated:
*errp = 0;
brelse(bitmap_bh);
- if (num *count) {
+ if (num = *count)
dquot_free_block_nodirty(inode, *count-num);
- mark_inode_dirty(inode);
- *count = num;
- }
+ mark_inode_dirty(inode);
+ *count = num;
return ret_block;
io_error:
However, I'm not familiar with ext2 source code and cannot tell if
this is the correct fix. At least it fixes my issue.
With this, you have essentially reverted a hunk from commit
8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b. But I don't see a reason why it
should be reverted. num should never ever be greater than *count and when
num == count, we the code inside if doesn't do anything useful.
I've looked into the code and I think I see the problem. It is a long
standing bug in __ext2_get_block() in fs/ext2/xip.c. It calls
ext2_get_block() asking for 0 blocks to map (while we really want 1 block).
ext2_get_block() just passes that request and ext2_get_blocks() actually
allocates 1 block. And that's were the commit you have identified makes a
difference because previously we returned that 1 block was allocated while
now we return that 0 blocks were allocated and thus allocation is repeated
until all free blocks are exhaused.
Attached patch should fix the problem.
Thanks for the reply. I've verified that your patch fixes my issue.
And it's absolutely better than my solution.
Tested-by: Andiry Xu andiry...@gmail.com
I have another question about ext2 XIP performance, although it's not
quite related to this thread.
I'm testing xip with ext2 on a ram disk drive, the driver is brd.c.
The RAM disk size is 2GB and I pre-fill it to guarantee that all pages
reside in main memory.
Then I use two different applications to write to the ram disk. One is
open() with O_DIRECT flag, and writing with Posix write(). Another is
open() with O_DIRECT, mmap() it to user space, then use memcpy() to
write data. I use different request size to write data, from 512 bytes
to 64MB.
In my understanding, the mmap version bypasses the file system and
does not go to kernel space, hence it should have better performance
than the Posix-write version. However, my test result shows it's not
always true: when the request size is between 8KB and 1MB, the
Posix-write() version has bandwidth about 7GB/s and mmap version only
has 5GB/s. The test is performed on a i7-3770K machine with 8GB
memory, kernel 3.12. Also I have tested on kernel 3.2, in which mmap
has really bad performance, only 2GB/s for all request sizes.
Do you know the reason why write() outperforms mmap() in some cases? I
know it's not related the thread but I really appreciate if you can
answer my question.
Thanks,
Andiry
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] libata: avoid waking disk to check power
+linux-ide
On 11/05/2013 08:53 AM, Phillip Susi wrote:
When a disk is in SLEEP mode it can not respond to commands,
including the CHECK POWER command. Instead of waking up the
sleeping disk, fake the reply to the CHECK POWER command to
indicate the disk is in standby mode. This prevents udisks
from waking up sleeping disks when it polls to see if they
are awake or not before trying to read their smart status.
If the disk entered sleep mode due to runtime PM, then udisks can easily
tell by checking the device's runtime status and not send out the query.
But if the disk entered sleep mode due to other reason, the patch may be
necessary. So what's your scenario?
Best regards,
Aaron
Signed-off-by: Phillip Susi ps...@ubuntu.com
---
drivers/ata/libata-core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 83b1a9f..573d151 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5084,6 +5084,13 @@ void ata_qc_issue(struct ata_queued_cmd *qc)
/* if device is sleeping, schedule reset and abort the link */
if (unlikely(qc-dev-flags ATA_DFLAG_SLEEPING)) {
+ if (unlikely(qc-tf.command == ATA_CMD_CHK_POWER))
+ {
+ /* fake reply to avoid waking drive */
+ qc-result_tf.nsect = 0;
+ ata_qc_complete(qc);
+ return;
+ }
link-eh_info.action |= ATA_EH_RESET;
ata_ehi_push_desc(link-eh_info, waking up from sleep);
ata_link_abort(link);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On 11/05/2013 10:22 AM, Chen Gang wrote:
On 11/05/2013 05:54 AM, Joe Perches wrote:
Add this to try this...
Chen Gang's defect is because his git repository branch
had a commit he authored but where did not add his signature.
Hmm... in fact, when I make a patch, I really let git log contents a
commit I author but where do not add my signature.
But after I let it pure next-20131101 (git reset HEAD^; git stash), it
still cause this issue.
Hmm... for pure next-20131101 tree in my git directory and the demo
patches in attachment, it will cause this issue.
And excuse me, I am not quite familiar with git, could you provide more
details (e.g. where the special difference of the demo patches or the
pure next-20131101 tree in my git directory)? thanks.
Also, there's a defect in function vcs_find_signers.
It should only return the commit count and array references.
If there are no signers in the commit history interval specified,
then the authors array is added to the signers array and
returned as a single array.
Use references instead.
Make sure that references are defined in the places
that vcs_find_signers is called.
After apply the patch below, it can work well.
Tested-by Chen Gang gang.c...@asianux.com
Signed-off-by: Joe Perches j...@perches.com
---
scripts/get_maintainer.pl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ee9adb8..9c3986f 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -128,7 +128,7 @@ my %VCS_cmds_git = (
blame_commit_pattern = ^([0-9a-f]+) ,
author_pattern = ^GitAuthor: (.*),
subject_pattern = ^GitSubject: (.*),
-stat_pattern = (\\d+)\\t(\\d+)\\t\$file,
+stat_pattern = ^(\\d+)\\t(\\d+)\\t\$file\$,
);
my %VCS_cmds_hg = (
@@ -156,7 +156,7 @@ my %VCS_cmds_hg = (
blame_commit_pattern = ^([ 0-9a-f]+):,
author_pattern = ^HgAuthor: (.*),
subject_pattern = ^HgSubject: (.*),
-stat_pattern = (\\d+)\t(\\d+)\t\$file,
+stat_pattern = ^(\\d+)\t(\\d+)\t\$file\$,
);
my $conf = which_conf(.get_maintainer.conf);
@@ -1297,7 +1297,7 @@ sub vcs_find_signers {
#print(stats: @stats\n);
-return (0, @signatures, @authors) if !@signatures;
+return (0, \@signatures, \@authors, \@stats) if !@signatures;
save_commits_by_author(@lines) if ($interactive);
save_commits_by_signer(@lines) if ($interactive);
@@ -1880,9 +1880,10 @@ sub vcs_file_signoffs {
$cmd =~ s/(\$\w+)/$1/eeg; # interpolate $cmd
($commits, $signers_ref, $authors_ref, $stats_ref) =
vcs_find_signers($cmd, $file);
-@signers = @{$signers_ref};
-@authors = @{$authors_ref};
-@stats = @{$stats_ref};
+
+@signers = @{$signers_ref} if defined $signers_ref;
+@authors = @{$authors_ref} if defined $authors_ref;
+@stats = @{$stats_ref} if defined $stats_ref;
#print(commits: $commits\nsigners:@signers\nauthors:
@authors\nstats: @stats\n);
@@ -1965,8 +1966,8 @@ sub vcs_file_blame {
$cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
($commit_count, $commit_signers_ref, $commit_authors_ref,
$stats_ref) = vcs_find_signers($cmd, $file);
-@commit_authors = @{$commit_authors_ref};
-@commit_signers = @{$commit_signers_ref};
+@commit_authors = @{$commit_authors_ref} if defined
$commit_authors_ref;
+@commit_signers = @{$commit_signers_ref} if defined
$commit_signers_ref;
push(@signers, @commit_signers);
} else {
@@ -1983,8 +1984,8 @@ sub vcs_file_blame {
$cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
($commit_count, $commit_signers_ref, $commit_authors_ref,
$stats_ref) = vcs_find_signers($cmd, $file);
-@commit_authors = @{$commit_authors_ref};
-@commit_signers = @{$commit_signers_ref};
+@commit_authors = @{$commit_authors_ref} if defined
$commit_authors_ref;
+@commit_signers = @{$commit_signers_ref} if defined
$commit_signers_ref;
push(@signers, @commit_signers);
}
--
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] libata: use sleep instead of standby command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:23 PM, Aaron Lu wrote: I suppose this is mainly for runtime PM? Since for system suspend/hibernation, the disk and its controller will be powered off anyway. Yes, or the second patch also helps when one manually issues hdparm - -Y, which otherwise will cause the drive to be woken up to answer the CHECK POWER command, which udisks issues to decide if it should skip polling the SMART status of the drive. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFpOAAoJEJrBOlT6nu75JdwIALFvwncNyf1ENxnIho2Y3CXC N6BpHQ7CzD1tap/5ybSFPBvUvJfyC/UPAY69bjldOtbwnArDIWRFqEWW7JWm6G0z J1C5MMCIRHSuRo4RbN/rnsPQFsaFJy0Z5kJ0uXX+aOrZwEov5vo2MEuj/DEdCBDC SKpYkogDlSHTNhFsaEF5iJiJlLU9FF5pEM6S6P0/+Z+SrZ5PVCDOm9rK+oeqrn0U TBX5tKPxWRSjJ/2F094DYia5l8ODNgzl1gPDXA50a+A4M0CZi3d5Liz5Ctfnv88A ac5cG8Ae8MDss0kJmSMCuRwkKVIROM3qMxf1wDWjBwm3eCTAJV1gxRYSN0adOvc= =Rfny -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] vfs: don't revalidate dentries that serve as mountpoints
On Mon, 4 Nov 2013 20:16:26 -0500 Jeff Layton jlay...@redhat.com wrote:
We had a couple of reports of people that are mounting NFS filesystems,
and then bind mounting certain local files onto dentries in that nfs
mount (sort of like a poor-man's unionmount).
This all works well until the dentry serving as the mountpoint fails
d_revalidate. The dentry will end up being invalidated which makes the
bind mount unreachable via pathwalk.
It doesn't make much sense to me to allow dentries to serve as
mountpoints to end up invalidated, so there's no real point in
attempting to d_revalidate them at all.
Reported-by: Patrick McLean chutz...@gentoo.org
Reported-by: Guang Cheng Li ligua...@cn.ibm.com
Signed-off-by: Jeff Layton jlay...@redhat.com
---
fs/namei.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/namei.c b/fs/namei.c
index caa2805..5b10ad0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -585,6 +585,9 @@ drop_root_mnt:
static inline int d_revalidate(struct dentry *dentry, unsigned int flags)
{
+ /* dentries that serve as mountpoints are always considered valid */
+ if (d_mountpoint(dentry))
+ return 1;
return dentry-d_op-d_revalidate(dentry, flags);
}
Makes sense to me. But what about the parent or grandparent of the mountpoint?
Presumably we don't want to invalidate them either, and I don't think
d_mountpoint() returns true for those, does it?
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH 1/2] libata: use sleep instead of standby command
On 11/05/2013 10:39 AM, Phillip Susi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:23 PM, Aaron Lu wrote: I suppose this is mainly for runtime PM? Since for system suspend/hibernation, the disk and its controller will be powered off anyway. Yes, or the second patch also helps when one manually issues hdparm - -Y, which otherwise will cause the drive to be woken up to answer the CHECK POWER command, which udisks issues to decide if it should skip polling the SMART status of the drive. OK, I see. I wish udidks can do both of these(polling smart status and put the disk into sleep mode), so that it knows when the disk is in sleep mode and it will not send out the needless poll... -Aaron -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] libata: avoid waking disk to check power
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:39 PM, Aaron Lu wrote: If the disk entered sleep mode due to runtime PM, then udisks can easily tell by checking the device's runtime status and not send out the query. But if the disk entered sleep mode due to other reason, the patch may be necessary. So what's your scenario? I am planning on patching udisks to do that as well, but if you have a current udsisk or manually run hdparm -C, or some other program is doing something similar, then this patch takes care of that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFvFAAoJEJrBOlT6nu75hcYH/0YsYcs3u9Dmuqq9z5kFXL3k C4xYQtvOxw2z+B/vEFzdym5J3ZfVyT4+ZdcHMvRgbbPH+R8/rzNC+F3OjdGtDIRA 5EUo0BUT2IfY0Yp2SzP44+8aRC4iF5jLLcH9XJKQx7WHedJQ7puCgJXXHAgUhpwW 52gJ0UEHnjlBgjwxY9RKqppnJs57x2VwgwR2BeFns6Hcry0S0HN0U4gwROmb1GZR kjpOUUYHb3MH/gfzCaY97t0duAAp7jzZeOIuu+XHfkyV3APwsnbasLOOoRYtpbvQ M++xmYQdNAh2DcZLEmAo6H6HLB/Z5d9K0+SKUFnsKHFaUCH0GPHm8SZ7E/NN7ig= =7c7v -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 19:47:41 +0100, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function in libc
and want to dump the variable in libc...
So probably I was wrong and this all needs more thinking. Damn.
Perhaps we really need to pass @file/offset, but it is not clear what
we can do with bss/anon-mapping.
Or. Not that I really like this, but just for discussion...
How about
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
addr)
{
return (void __force __user *)addr + instruction_pointer(regs);
}
?
This should solve the problems with relocations/randomization/bss.
Right. I think this approach is more reliable than playing with vma.
The obvious disadvantage is that it is not easy to calculate the
offset we need to pass as an argument, it depends on the probed
function.
Well, maybe it's not that hard if we use symbol address in elf image
rather than file offset for the data.
IOW we can get the base mapping address by subtracting tu-offset from
instruction pointer. And then adding symbol address of the data should
give us the final virtual address, yay!
I'll try to play with it after lunch.
And this still doesn't allow to, say, probe the executable but read
the data from libc. Unless, again, we attach to the running process
or randomize_va_space = 0, so we can know it in advance. But otherwise
I do not think there is any solution.
Yes, cross-fetching is hard, let's go lunch. :)
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the device-mapper tree
Hi all,
After merging the device-mapper tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-cache-target.c: In function 'bio_writes_complete_block':
drivers/md/dm-cache-target.c:1020:7: error: 'struct bio' has no member named
'bi_size'
(bio-bi_size == (cache-sectors_per_block SECTOR_SHIFT));
^
Caused by commit 1bd270d800ec (dm cache: promotion optimisation for
writes) interacting with commit ed2d2f9a8265 (block: Abstract out bvec
iterator) from the block tree.
I applied this fix up patch and can carry it as necessary:
From: Stephen Rothwell s...@canb.auug.org.au
Date: Tue, 5 Nov 2013 13:49:25 +1100
Subject: [PATCH] dm_cache: fix up for bvec iterator abstraction
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
drivers/md/dm-cache-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index a977d5c6d544..5ce0f5ec6d74 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -1017,7 +1017,7 @@ static void issue_overwrite(struct dm_cache_migration
*mg, struct bio *bio)
static bool bio_writes_complete_block(struct cache *cache, struct bio *bio)
{
return (bio_data_dir(bio) == WRITE)
- (bio-bi_size == (cache-sectors_per_block SECTOR_SHIFT));
+ (bio-bi_iter.bi_size == (cache-sectors_per_block
SECTOR_SHIFT));
}
static void avoid_copy(struct dm_cache_migration *mg)
--
1.8.4.rc3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpv9OhCKl6a4.pgp
Description: PGP signature
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function in libc
and want to dump the variable in libc...
So probably I was wrong and this all needs more thinking. Damn.
Perhaps we really need to pass @file/offset, but it is not clear what
we can do with bss/anon-mapping.
Or. Not that I really like this, but just for discussion...
How about
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
addr)
{
return (void __force __user *)addr + instruction_pointer(regs);
}
?
This should solve the problems with relocations/randomization/bss.
The obvious disadvantage is that it is not easy to calculate the
offset we need to pass as an argument, it depends on the probed
function.
forgot to mention... and instruction_pointer() can't work in ret-probe,
we need to pass the unsigned long func arg somehow...
Hmm.. what's the value of tu-offset in this case? Does it have the
offset of the return address or the start of the function?
Anyway, what we really need is the base address of the text mapping
IMHO.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] vfs: don't revalidate dentries that serve as mountpoints
For a similar issue in cifs vfs (samba bugzilla 8950), I was going to try
unset the bit DCACHE_OP_REVALIDATE of d_flags of the
dentry. Would something like work for the mountpoint dentry?
On Mon, Nov 4, 2013 at 7:16 PM, Jeff Layton jlay...@redhat.com wrote:
We had a couple of reports of people that are mounting NFS filesystems,
and then bind mounting certain local files onto dentries in that nfs
mount (sort of like a poor-man's unionmount).
This all works well until the dentry serving as the mountpoint fails
d_revalidate. The dentry will end up being invalidated which makes the
bind mount unreachable via pathwalk.
It doesn't make much sense to me to allow dentries to serve as
mountpoints to end up invalidated, so there's no real point in
attempting to d_revalidate them at all.
Reported-by: Patrick McLean chutz...@gentoo.org
Reported-by: Guang Cheng Li ligua...@cn.ibm.com
Signed-off-by: Jeff Layton jlay...@redhat.com
---
fs/namei.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/namei.c b/fs/namei.c
index caa2805..5b10ad0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -585,6 +585,9 @@ drop_root_mnt:
static inline int d_revalidate(struct dentry *dentry, unsigned int flags)
{
+ /* dentries that serve as mountpoints are always considered valid */
+ if (d_mountpoint(dentry))
+ return 1;
return dentry-d_op-d_revalidate(dentry, flags);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-nfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: converting unicore32 to gate_vma as done for arm (was Re: [PATCH] mm: cache largest vma)
The patch is ok for unicore32. Thanks Al.
While testing this patch, a bug is found in
arch/unicore32/include/asm/pgtable.h:
@@ -96,7 +96,7 @@ extern pgprot_t pgprot_kernel;
| PTE_EXEC)
#define PAGE_READONLY __pgprot(pgprot_val(pgprot_user | PTE_READ)
#define PAGE_READONLY_EXEC __pgprot(pgprot_val(pgprot_user | PTE_READ \
- | PTE_EXEC)
+ | PTE_EXEC))
In fact, all similar macros are wrong. I'll post an bug-fix patch for this
obvious error.
Xuetao
- Al Viro v...@zeniv.linux.org.uk 写道：
On Sun, Nov 03, 2013 at 08:20:10PM -0800, Davidlohr Bueso wrote:
diff --git a/arch/unicore32/include/asm/mmu_context.h
b/arch/unicore32/include/asm/mmu_context.h
index fb5e4c6..38cc7fc 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -73,7 +73,7 @@ do { \
else \
mm-mmap = NULL; \
rb_erase(high_vma-vm_rb, mm-mm_rb); \
- mm-mmap_cache = NULL; \
+ vma_clear_caches(mm); \
mm-map_count--; \
remove_vma(high_vma); \
} \
BTW, this one needs an analog of
commit f9d4861fc32b995b1616775614459b8f266c803c
Author: Will Deacon will.dea...@arm.com
Date: Fri Jan 20 12:01:13 2012 +0100
ARM: 7294/1: vectors: use gate_vma for vectors user mapping
This code is a copy of older arm logics rewritten in that commit; unicore32
never got its counterpart. I have a [completely untested] variant sitting
in vfs.git#vm^; it's probably worth testing - if it works, we'll get rid
of one more place that needs to be aware of MM guts and unicore32 folks
will have fewer potential headache sources...
FWIW, after porting to the current tree it becomes the following; I'm not
sure whether we want VM_DONTEXPAND | VM_DONTDUMP set for this one, though...
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
diff --git a/arch/unicore32/include/asm/elf.h
b/arch/unicore32/include/asm/elf.h
index 829042d..eeba258 100644
--- a/arch/unicore32/include/asm/elf.h
+++ b/arch/unicore32/include/asm/elf.h
@@ -87,8 +87,4 @@ struct mm_struct;
extern unsigned long arch_randomize_brk(struct mm_struct *mm);
#define arch_randomize_brk arch_randomize_brk
-extern int vectors_user_mapping(void);
-#define arch_setup_additional_pages(bprm, uses_interp) vectors_user_mapping()
-#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
-
#endif
diff --git a/arch/unicore32/include/asm/mmu_context.h
b/arch/unicore32/include/asm/mmu_context.h
index fb5e4c6..600b1b8 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -18,6 +18,7 @@
#include asm/cacheflush.h
#include asm/cpu-single.h
+#include asm-generic/mm_hooks.h
#define init_new_context(tsk, mm)0
@@ -56,32 +57,4 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
#define deactivate_mm(tsk, mm) do { } while (0)
#define activate_mm(prev, next) switch_mm(prev, next, NULL)
-/*
- * We are inserting a fake vma for the user-accessible vector page so
- * gdb and friends can get to it through ptrace and /proc/pid/mem.
- * But we also want to remove it before the generic code gets to see it
- * during process exit or the unmapping of it would cause total havoc.
- * (the macro is used as remove_vma() is static to mm/mmap.c)
- */
-#define arch_exit_mmap(mm) \
-do { \
- struct vm_area_struct *high_vma = find_vma(mm, 0x); \
- if (high_vma) { \
- BUG_ON(high_vma-vm_next); /* it should be last */ \
- if (high_vma-vm_prev) \
- high_vma-vm_prev-vm_next = NULL; \
- else \
- mm-mmap = NULL; \
- rb_erase(high_vma-vm_rb, mm-mm_rb); \
- mm-mmap_cache = NULL; \
- mm-map_count--; \
- remove_vma(high_vma); \
- } \
-} while (0)
-
-static inline void arch_dup_mmap(struct mm_struct *oldmm,
- struct mm_struct *mm)
-{
-}
-
#endif
diff --git a/arch/unicore32/include/asm/page.h
b/arch/unicore32/include/asm/page.h
index 594b322..e79da8b 100644
--- a/arch/unicore32/include/asm/page.h
+++ b/arch/unicore32/include/asm/page.h
@@ -28,6 +28,8 @@ extern void copy_page(void *to, const void *from);
#define clear_user_page(page, vaddr, pg) clear_page(page)
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
+#define __HAVE_ARCH_GATE_AREA 1
+
#undef STRICT_MM_TYPECHECKS
#ifdef STRICT_MM_TYPECHECKS
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index 778ebba..51d129e 100644
--- a/arch/unicore32/kernel/process.c
+++
[PATCH] pwm: samsung: memory leak bugfix in pwm_samsung_free
There is certainly a kind of memory leak since allocated data (i.e.
chip_data) is set NULL before freeing it by calling devm_kfree(). This
patch fixes the memory leak bug by modifying its call order.
Signed-off-by: Sangjung Woo sangjung@samsung.com
Reviewed-by: Jonghwa Lee jonghwa3@samsung.com
---
drivers/pwm/pwm-samsung.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index fcc8b9a..07b2d9d 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -224,8 +224,8 @@ static int pwm_samsung_request(struct pwm_chip *chip,
struct pwm_device *pwm)
static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
- pwm_set_chip_data(pwm, NULL);
devm_kfree(chip-dev, pwm_get_chip_data(pwm));
+ pwm_set_chip_data(pwm, NULL);
}
static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t
On Mon, Nov 04, 2013 at 05:44:00PM -0800, Tim Chen wrote:
On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote:
On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote:
On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
Btw., another _really_ interesting comparison would be against
the latest rwsem patches. Mind doing such a comparison?
Sure. Where can I get it? Are they on some git tree?
I've Cc:-ed Tim Chen who might be able to point you to the latest
version.
The last on-lkml submission was in this thread:
Subject: [PATCH v8 0/9] rwsem performance optimizations
Thanks.
I queued bunchs of tests about one hour ago, and already got some
results(If necessary, I can add more data tomorrow when those tests are
finished):
What kind of system are you using to run these workloads on?
I queued jobs on 5 testboxes:
- brickland1: 120 core Ivybridge server
- lkp-ib03: 48 core Ivybridge server
- lkp-sb03: 32 core Sandybridge server
- lkp-nex04: 64 core NHM server
- lkp-a04:Atom server
v3.12-rc7 fe001e3de090e179f95d
-9.3%
brickland1/micro/aim7/shared
+4.3%
lkp-ib03/micro/aim7/fork_test
+2.2%
lkp-ib03/micro/aim7/shared
-2.6% TOTAL
aim7.2000.jobs-per-min
Sorry if I'm missing something, but could you elaborate more on what
these percentages represent?
v3.12-rc7 fe001e3de090e179f95d
-9.3%
brickland1/micro/aim7/shared
-2.6% TOTAL
aim7.2000.jobs-per-min
The comparation base is v3.12-rc7, and we got 9.3 performance regression
at commit fe001e3de090e179f95d, which is the head of rwsem performance
optimizations patch set.
Yunahan, thanks for the data. This I assume is with the entire rwsem
v8 patchset.
Yes, it is; 9 patches in total.
Any idea of the run variation on the workload?
Your concern is right. The variation is quite big on the
brickland1/micro/aim7/shared
testcase.
* - v3.12-rc7
O - fe001e3de090e179f95d
brickland1/micro/aim7/shared: aim7.2000.jobs-per-min
32 +++
| |
31 ++ .*. |
| ...|
30 ++ ... |
|... .. |
29 ++ ...|
| *
28 ++... |
| |
27 ++|
*.O
26 O+|
|O|
25 +++
--yliu
brickland1/micro/aim7/shared tells the testbox(brickland1) and testcase:
shared workfile of aim7.
The last line tell what field we are comparing, and it's
aim7.2000.jobs-per-min in this case. 2000 means 2000 users in aim7.
Are they anon vma rwsem + optimistic
spinning patches vs anon vma rwlock?
I tested [PATCH v8 0/9] rwsem performance optimizations only.
Also, I see your running aim7, you might be interested in some of the
results I found when trying out Ingo's rwlock conversion patch on a
largish 80 core system: https://lkml.org/lkml/2013/9/29/280
Besides aim7, I also tested dbench, hackbench, netperf, pigz. And as you
can image and see from the data, aim7 benifit most from the anon_vma
optimization stuff due to high contention of anon_vma lock.
Thanks.
--yliu
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH 1/1] cpufreq: cpufreq-cpu0: use the max voltage instead of voltage-tolerance
From: Rongjun Ying rongjun.y...@csr.com
Sometime the regulator can't supply appropriate voltages for requestion of cpu.
All voltage tolerance value can't figure out a good voltage.
Signed-off-by: Rongjun Ying rongjun.y...@csr.com
---
drivers/cpufreq/cpufreq-cpu0.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index c522a95..0c9e6b9 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -23,7 +23,7 @@
#include linux/slab.h
static unsigned int transition_latency;
-static unsigned int voltage_tolerance; /* in percentage */
+static unsigned int voltage_max;
static struct device *cpu_dev;
static struct clk *cpu_clk;
@@ -45,7 +45,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
{
struct cpufreq_freqs freqs;
struct opp *opp;
- unsigned long volt = 0, volt_old = 0, tol = 0;
+ unsigned long volt = 0, volt_old = 0;
long freq_Hz, freq_exact;
unsigned int index;
int ret;
@@ -82,7 +82,6 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
}
volt = opp_get_voltage(opp);
rcu_read_unlock();
- tol = volt * voltage_tolerance / 100;
volt_old = regulator_get_voltage(cpu_reg);
}
@@ -92,7 +91,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
/* scaling up? scale voltage before frequency */
if (!IS_ERR(cpu_reg) freqs.new freqs.old) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
if (ret) {
pr_err(failed to scale voltage up: %d\n, ret);
freqs.new = freqs.old;
@@ -104,14 +103,14 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
if (ret) {
pr_err(failed to set clock rate: %d\n, ret);
if (!IS_ERR(cpu_reg))
- regulator_set_voltage_tol(cpu_reg, volt_old, tol);
+ regulator_set_voltage(cpu_reg, volt_old, voltage_max);
freqs.new = freqs.old;
goto post_notify;
}
/* scaling down? scale voltage after frequency */
if (!IS_ERR(cpu_reg) freqs.new freqs.old) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
if (ret) {
pr_err(failed to scale voltage down: %d\n, ret);
clk_set_rate(cpu_clk, freqs.old * 1000);
@@ -224,7 +223,11 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_put_node;
}
- of_property_read_u32(np, voltage-tolerance, voltage_tolerance);
+ ret = of_property_read_u32(np, voltage-max, voltage_max);
+ if (ret) {
+ pr_err(failed to get max voltage: %d\n, ret);
+ goto out_put_node;
+ }
if (of_property_read_u32(np, clock-latency, transition_latency))
transition_latency = CPUFREQ_ETERNAL;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
(2013/11/05 11:00), Steven Rostedt wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and kernel will
reboot.
This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Borislav Petkov b...@suse.de
Cc: Ingo Molnar mi...@kernel.org
---
kernel/extable.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/extable.c b/kernel/extable.c
index 832cb28..022fb25 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
* pointer is part of the kernel text, we need to do some
* special dereferencing first.
*/
-int func_ptr_is_kernel_text(void *ptr)
+int nokprobe func_ptr_is_kernel_text(void *ptr)
{
unsigned long addr;
addr = (unsigned long) dereference_function_descriptor(ptr);
One thing I worry about the nokprobe annotation, is that it moves the
location of the function out of local. This function no exists in
the section with its users. Same with the debug functions in the
other patch.
Now these may be a slow path where we really don't care, but if the
nokprobe expands this can cause issues.
The nokprobe works differently than notrace as notrace is just an
attribute that tells gcc not to add mcount to it. The nokprobe
actually moves the function into a different section.
Well, in that case, I can put it in the opt-out type
blacklist(kprobe_blacklist). :)
Hmm, I think if I can list nokprobe functions up at build time, we can almost
remove the .kprobes.text (Note that some of entry functions in asm still
require it.)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the device-mapper tree
On Mon, Nov 04 2013 at 9:51pm -0500,
Stephen Rothwell s...@canb.auug.org.au wrote:
Hi all,
After merging the device-mapper tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-cache-target.c: In function 'bio_writes_complete_block':
drivers/md/dm-cache-target.c:1020:7: error: 'struct bio' has no member named
'bi_size'
(bio-bi_size == (cache-sectors_per_block SECTOR_SHIFT));
^
Caused by commit 1bd270d800ec (dm cache: promotion optimisation for
writes) interacting with commit ed2d2f9a8265 (block: Abstract out bvec
iterator) from the block tree.
I applied this fix up patch and can carry it as necessary:
Hi Stephen,
Yes that is needed, as is this (which begs the question: how should I be
handling the fact that post-merge changes are needed? Especially since
Linus will need the changes too):
drivers/md/dm-cache-target.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index a977d5c..52d7d75 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -85,6 +85,12 @@ static void dm_unhook_bio(struct dm_hook_info *h, struct bio
*bio)
{
bio-bi_end_io = h-bi_end_io;
bio-bi_private = h-bi_private;
+
+ /*
+* Must bump bi_remaining to allow bio to complete with
+* restored bi_end_io.
+*/
+ atomic_inc(bio-bi_remaining);
}
/**/
@@ -746,12 +752,6 @@ static void writethrough_endio(struct bio *bio, int err)
dm_unhook_bio(pb-hook_info, bio);
- /*
-* Must bump bi_remaining to allow bio to complete with
-* restored bi_end_io.
-*/
- atomic_inc(bio-bi_remaining);
-
if (err) {
bio_endio(bio, err);
return;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warnings after merge of the modules tree
Stephen Rothwell s...@canb.auug.org.au writes:
Hi Rusty,
After merging the modules tree, today's linux-next build (x86_64
allmodconfig) produced these warning:
WARNING: vmlinux: 'pci_restore_msi_state' exported twice. Previous export was
in vmlinux
WARNING: vmlinux: '__mod_zone_page_state' exported twice. Previous export was
in vmlinux
WARNING: vmlinux: 'scsi_prep_return' exported twice. Previous export was in
vmlinux
WARNING: vmlinux: 'hvc_poll' exported twice. Previous export was in vmlinux
WARNING: vmlinux: 'nfs_clear_inode' exported twice. Previous export was in
vmlinux
(just some samples ... it scrolled off my scrollback :-()
Presumably caused by commit e0f244c63fc9 (asmlinkage, module: Make
ksymtab and kcrctab symbols and __this_module __visible). (reverting
that commit makes the warnings go away.)
This works for me feedback please!
Cheers,
Rusty.
modpost: fix bogus 'exported twice' warnings.
Andi's change in e0f244c63fc9 (asmlinkage, module: Make ksymtab and
kcrctab symbols and __this_module __visible) make the crc appear
first in the symbol table.
modpost creates an entry when it sees the CRC, then when it sees the
actual symbol, it complains that it's seen it before. The preloaded
flag already exists for the equivalent case where we loaded from
Module.symvers, so use that.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 9b873ac6ed7b..5c677a3e7487 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -164,7 +164,7 @@ struct symbol {
unsigned int vmlinux:1;/* 1 if symbol is defined in vmlinux */
unsigned int kernel:1; /* 1 if symbol is from kernel
* (only for external modules) **/
- unsigned int preloaded:1; /* 1 if symbol from Module.symvers */
+ unsigned int preloaded:1; /* 1 if symbol from Module.symvers, or crc */
enum export export; /* Type of export */
char name[0];
};
@@ -332,8 +332,11 @@ static void sym_update_crc(const char *name, struct module
*mod,
{
struct symbol *s = find_symbol(name);
- if (!s)
+ if (!s) {
s = new_symbol(name, mod, export);
+ /* Don't complain when we find it later. */
+ s-preloaded = 1;
+ }
s-crc = crc;
s-crc_valid = 1;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] drivers: xen-selfballoon: consider slab pages
On 11/05/2013 01:22 AM, David Vrabel wrote: On 04/11/13 12:39, Bob Liu wrote: Currently the goal_page in xen-selfballon doesn't consider much about pages used in kernel space. A typical usage is slab pages, without consider slab pages the goal_page result may be too rough and lead extra memory pressure to guest os. Can you provide some real world figures where the calculatation got it wrong? What was the resultant behavior? Swap death? OOM killer? Sorry, I didn't run any testing I just think it's unreasonable while reading the source code. vm_memory_committed() only calculate pages which mapped to process address space, but the kernel itself(like block, fs and network subsystem) may occupy some memory. And it's possible that those subsystem may occupy a significant amount of memory in some situation. I'm afraid if we don't consider those kernel memory while calculating goal_pages, guest memory will be set lower than guest really needs. Signed-off-by: Bob Liu bob@oracle.com --- drivers/xen/xen-selfballoon.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c index 21e18c1..4814759 100644 --- a/drivers/xen/xen-selfballoon.c +++ b/drivers/xen/xen-selfballoon.c @@ -191,6 +191,8 @@ static void selfballoon_process(struct work_struct *work) tgt_pages = cur_pages; /* default is no change */ goal_pages = vm_memory_committed() + totalreserve_pages + +global_page_state(NR_SLAB_RECLAIMABLE) + Does SLAB_RECLAIMABLE want to be included here? Unless I'm misunderstanding here, SLAB_RECLAIMABLE is effectively free. SLAB_RECLAIMABLE isn't effectively free, it means the slab page is in used but can be reclaimed(freed) during memory pressure. +global_page_state(NR_SLAB_UNRECLAIMABLE) + This bit looks fine to me. MB2PAGES(selfballoon_reserved_mb); #ifdef CONFIG_FRONTSWAP /* allow space for frontswap pages to be repatriated */ David Thanks for your review. -- Regards, -Bob -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the device-mapper tree
Hi Mike, On Mon, 4 Nov 2013 22:20:54 -0500 Mike Snitzer snit...@redhat.com wrote: On Mon, Nov 04 2013 at 9:51pm -0500, Stephen Rothwell s...@canb.auug.org.au wrote: After merging the device-mapper tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/md/dm-cache-target.c: In function 'bio_writes_complete_block': drivers/md/dm-cache-target.c:1020:7: error: 'struct bio' has no member named 'bi_size' (bio-bi_size == (cache-sectors_per_block SECTOR_SHIFT)); ^ Caused by commit 1bd270d800ec (dm cache: promotion optimisation for writes) interacting with commit ed2d2f9a8265 (block: Abstract out bvec iterator) from the block tree. I applied this fix up patch and can carry it as necessary: Yes that is needed, as is this (which begs the question: how should I be I will add that tomorrow. handling the fact that post-merge changes are needed? Especially since Linus will need the changes too): Who ever gets their tree in last has to tell Linus about these extra merge fix ups as part of their pull request. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpKBFAOR4fez.pgp Description: PGP signature
Re: [PATCH] pwm: samsung: memory leak bugfix in pwm_samsung_free
Hi Sangjung,
On 5 November 2013 08:32, Sangjung Woo sangjung@samsung.com wrote:
There is certainly a kind of memory leak since allocated data (i.e.
chip_data) is set NULL before freeing it by calling devm_kfree(). This
patch fixes the memory leak bug by modifying its call order.
Signed-off-by: Sangjung Woo sangjung@samsung.com
Reviewed-by: Jonghwa Lee jonghwa3@samsung.com
---
drivers/pwm/pwm-samsung.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index fcc8b9a..07b2d9d 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -224,8 +224,8 @@ static int pwm_samsung_request(struct pwm_chip *chip,
struct pwm_device *pwm)
static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
- pwm_set_chip_data(pwm, NULL);
devm_kfree(chip-dev, pwm_get_chip_data(pwm));
+ pwm_set_chip_data(pwm, NULL);
}
Similar patch has already been applied by Thierry.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] toshiba_acpi: Add platform support
Add platform support and change the backlight
and led devices to register on it instead of the acpi_device.
The use of the platform is to have just one place where to
look for files instead of looking at the current three different
ACPI devices (TOS6200, TOS6208 and TOS1900) and thus making
userspace a bit easier.
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_acpi.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index d7ecef3..226e0b5 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -54,6 +54,7 @@
#include linux/slab.h
#include linux/workqueue.h
#include linux/i8042.h
+#include linux/platform_device.h
#include asm/uaccess.h
@@ -129,6 +130,7 @@ MODULE_LICENSE(GPL);
struct toshiba_acpi_dev {
struct acpi_device *acpi_dev;
+ struct platform_device *pf_dev;
const char *method_hci;
struct rfkill *bt_rfk;
struct input_dev *hotkey_dev;
@@ -1156,7 +1158,7 @@ static int toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
props.max_brightness++;
dev-backlight_dev = backlight_device_register(toshiba,
- dev-acpi_dev-dev,
+ dev-pf_dev-dev,
dev,
toshiba_backlight_data,
props);
@@ -1198,6 +1200,9 @@ static int toshiba_acpi_remove(struct acpi_device
*acpi_dev)
if (dev-illumination_supported)
led_classdev_unregister(dev-led_dev);
+ if (dev-pf_dev)
+ platform_device_unregister(dev-pf_dev);
+
if (toshiba_acpi)
toshiba_acpi = NULL;
@@ -1249,6 +1254,15 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
dev-method_hci = hci_method;
acpi_dev-driver_data = dev;
+ dev-pf_dev = platform_device_register_simple(toshiba, -1, NULL, 0);
+ if (IS_ERR(dev-pf_dev)) {
+ ret = PTR_ERR(dev-pf_dev);
+ pr_err(Unable to register platform device\n);
+ kfree(dev);
+ return ret;
+ }
+ platform_set_drvdata(dev-pf_dev, dev);
+
if (toshiba_acpi_setup_keyboard(dev))
pr_info(Unable to activate hotkeys\n);
@@ -1284,7 +1298,7 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
dev-led_dev.max_brightness = 1;
dev-led_dev.brightness_set = toshiba_illumination_set;
dev-led_dev.brightness_get = toshiba_illumination_get;
- if (!led_classdev_register(acpi_dev-dev, dev-led_dev))
+ if (!led_classdev_register(dev-pf_dev-dev, dev-led_dev))
dev-illumination_supported = 1;
}
@@ -1388,6 +1402,13 @@ static struct acpi_driver toshiba_acpi_driver = {
.drv.pm = toshiba_acpi_pm,
};
+static struct platform_driver platform_driver = {
+ .driver = {
+ .name = toshiba,
+ .owner = THIS_MODULE,
+ },
+};
+
static int __init toshiba_acpi_init(void)
{
int ret;
@@ -1406,6 +1427,12 @@ static int __init toshiba_acpi_init(void)
return -ENODEV;
}
+ ret = platform_driver_register(platform_driver);
+ if (ret 0) {
+ pr_err(Failed to register platform driver: %d\n, ret);
+ return ret;
+ }
+
ret = acpi_bus_register_driver(toshiba_acpi_driver);
if (ret) {
pr_err(Failed to register ACPI driver: %d\n, ret);
@@ -1418,6 +1445,7 @@ static int __init toshiba_acpi_init(void)
static void __exit toshiba_acpi_exit(void)
{
acpi_bus_unregister_driver(toshiba_acpi_driver);
+ platform_driver_unregister(platform_driver);
if (toshiba_proc_dir)
remove_proc_entry(PROC_TOSHIBA, acpi_root_dir);
}
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] toshiba_acpi: Add ECO led support
Newer Toshiba laptops now come with a feature called
ECO Mode, where the system is put in low power consupmtion
state and a green (world shaped with leaves) icon illuminates
indicating that the system is in such power state.
This patch adds support to turn on/off the ECO led by
creating and registering the toshiba::eco_mode led.
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_acpi.c | 66 +
1 file changed, 66 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index f97f942..022c6e6 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -113,6 +113,7 @@ MODULE_LICENSE(GPL);
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
#define HCI_KBD_ILLUMINATION 0x0095
+#define HCI_ECO_MODE 0x0097
#define SCI_ILLUMINATION 0x014e
#define SCI_KBD_ILLUM_STATUS 0x015c
@@ -143,6 +144,7 @@ struct toshiba_acpi_dev {
struct backlight_device *backlight_dev;
struct led_classdev led_dev;
struct led_classdev kbd_led;
+ struct led_classdev eco_led;
int force_fan;
int last_key_event;
@@ -159,6 +161,7 @@ struct toshiba_acpi_dev {
unsigned int tr_backlight_supported:1;
unsigned int kbd_illum_supported:1;
unsigned int kbd_led_registered:1;
+ unsigned int eco_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -538,6 +541,57 @@ static void toshiba_kbd_backlight_set(struct led_classdev
*cdev,
}
}
+/* Eco Mode support */
+static int toshiba_eco_mode_available(struct toshiba_acpi_dev *dev)
+{
+ acpi_status status;
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ECO_MODE, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_info(ACPI call to get ECO led failed\n);
+ return 0;
+ }
+
+ return 1;
+}
+
+static enum led_brightness toshiba_eco_mode_get_status(struct led_classdev
*cdev)
+{
+ struct toshiba_acpi_dev *dev = container_of(cdev,
+ struct toshiba_acpi_dev, eco_led);
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ECO_MODE, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err(ACPI call to get ECO led failed\n);
+ return LED_OFF;
+ }
+
+ return out[2] ? LED_FULL : LED_OFF;
+}
+
+static void toshiba_eco_mode_set_status(struct led_classdev *cdev,
+enum led_brightness brightness)
+{
+ struct toshiba_acpi_dev *dev = container_of(cdev,
+ struct toshiba_acpi_dev, eco_led);
+ u32 in[HCI_WORDS] = { HCI_SET, HCI_ECO_MODE, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ /* Switch the Eco Mode led on/off */
+ in[2] = (brightness) ? 1 : 0;
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err(ACPI call to set ECO led failed\n);
+ return;
+ }
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1413,6 +1467,9 @@ static int toshiba_acpi_remove(struct acpi_device
*acpi_dev)
if (dev-kbd_led_registered)
led_classdev_unregister(dev-kbd_led);
+ if (dev-eco_supported)
+ led_classdev_unregister(dev-eco_led);
+
if (dev-pf_dev)
platform_device_unregister(dev-pf_dev);
@@ -1515,6 +1572,15 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
dev-illumination_supported = 1;
}
+ if (toshiba_eco_mode_available(dev)) {
+ dev-eco_led.name = toshiba::eco_mode;
+ dev-eco_led.max_brightness = 1;
+ dev-eco_led.brightness_set = toshiba_eco_mode_set_status;
+ dev-eco_led.brightness_get = toshiba_eco_mode_get_status;
+ if (!led_classdev_register(dev-pf_dev-dev, dev-eco_led))
+ dev-eco_supported = 1;
+ }
+
ret = toshiba_kbd_illum_status_get(dev, dummy);
if (!ret) {
dev-kbd_time = dummy HCI_MISC_SHIFT;
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] toshiba_acpi: Add touchpad enable/disable support
Toshiba laptops have two ways of enabling/disabling the
touchpad, one with a hardwired button on top of the touchpad
that simply emmits scancodes to let userspace know it has changed,
and another with a SCI call that triggers (on Windows drivers)
whenever the user press the Fn-F9 (touchpad toggle) hotkey.
This patch adds support to enable/disable the touchpad
by exposing the _touchpad_ file in sysfs.
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_acpi.c | 81 +
1 file changed, 81 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 9c718eb..0e14e9c 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -120,6 +120,7 @@ MODULE_LICENSE(GPL);
#define HCI_ACCELEROMETER2 0x00a6
#define SCI_ILLUMINATION 0x014e
#define SCI_KBD_ILLUM_STATUS 0x015c
+#define SCI_TOUCHPAD 0x050e
/* field definitions */
#define HCI_ACCEL_MASK 0x7fff
@@ -168,6 +169,7 @@ struct toshiba_acpi_dev {
unsigned int kbd_led_registered:1;
unsigned int eco_supported:1;
unsigned int accelerometer_supported:1;
+ unsigned int touchpad_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -643,6 +645,47 @@ static int toshiba_accelerometer_get(struct
toshiba_acpi_dev *dev,
return 0;
}
+/* TouchPad support */
+static int toshiba_touchpad_set(struct toshiba_acpi_dev *dev, u32 state)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_write(dev, SCI_TOUCHPAD, state, result);
+ sci_close(dev);
+ if (ACPI_FAILURE(status)) {
+ pr_err(ACPI call to set the touchpad failed\n);
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int toshiba_touchpad_get(struct toshiba_acpi_dev *dev, u32 *state)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_read(dev, SCI_TOUCHPAD, state, result);
+ sci_close(dev);
+ if (ACPI_FAILURE(status)) {
+ pr_err(ACPI call to query the touchpad failed\n);
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1267,16 +1310,49 @@ static ssize_t toshiba_position_show(struct device *dev,
return sprintf(buf, %d %d %d\n, x, y, z);
}
+static ssize_t toshiba_touchpad_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ int state;
+
+ /* Set the TouchPad on/off, 0 - Disable | 1 - Enable */
+ if (sscanf(buf, %i, state) == 1 (state == 0 || state == 1)) {
+ if (toshiba_touchpad_set(toshiba, state) 0)
+ return -EIO;
+ }
+
+ return count;
+}
+
+static ssize_t toshiba_touchpad_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 state;
+ int ret;
+
+ ret = toshiba_touchpad_get(toshiba, state);
+ if (ret 0)
+ return ret;
+
+ return sprintf(buf, %i\n, state);
+}
+
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_backlight_timeout, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_timeout_show, toshiba_kbd_bl_timeout_store);
static DEVICE_ATTR(position, S_IRUGO, toshiba_position_show, NULL);
+static DEVICE_ATTR(touchpad, S_IRUGO | S_IWUSR,
+ toshiba_touchpad_show, toshiba_touchpad_store);
static struct attribute *toshiba_attributes[] = {
dev_attr_kbd_backlight_mode.attr,
dev_attr_kbd_backlight_timeout.attr,
dev_attr_position.attr,
+ dev_attr_touchpad.attr,
NULL,
};
@@ -1294,6 +1370,8 @@ static umode_t toshiba_sysfs_is_visible(struct kobject
*kobj,
exists = (driver-kbd_mode == SCI_KBD_MODE_AUTO) ? true : false;
else if (attr == dev_attr_position.attr)
exists = (driver-accelerometer_supported) ? true : false;
+ else if (attr == dev_attr_touchpad.attr)
+ exists = (driver-touchpad_supported) ? true : false;
return exists ? attr-mode : 0;
}
@@ -1679,6 +1757,9 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
ret = toshiba_accelerometer_supported(dev);
[PATCH 6/8] toshiba_acpi: Add accelerometer support
Recent Toshiba laptops now come equiped with a built in
accelerometer (TOS620A), but such device does not
expose the axis information, however, HCI calls 0x006d
and 0x00a6 can be used to query such info.
This patch adds support to read the axis values and
exposing them through the _position_ sysfs file.
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_acpi.c | 79 +
1 file changed, 79 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 022c6e6..9c718eb 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -103,6 +103,8 @@ MODULE_LICENSE(GPL);
#define INPUT_DATA_ERROR 0x8300
#define NOT_PRESENT0x8600
#define FIFO_EMPTY 0x8c00
+#define DATA_NOT_AVAILABLE 0x8d20
+#define NOT_INITIALIZED0x8d50
/* registers */
#define HCI_FAN0x0004
@@ -112,12 +114,15 @@ MODULE_LICENSE(GPL);
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
+#define HCI_ACCELEROMETER 0x006d
#define HCI_KBD_ILLUMINATION 0x0095
#define HCI_ECO_MODE 0x0097
+#define HCI_ACCELEROMETER2 0x00a6
#define SCI_ILLUMINATION 0x014e
#define SCI_KBD_ILLUM_STATUS 0x015c
/* field definitions */
+#define HCI_ACCEL_MASK 0x7fff
#define HCI_HOTKEY_DISABLE 0x0b
#define HCI_HOTKEY_ENABLE 0x09
#define HCI_LCD_BRIGHTNESS_BITS3
@@ -162,6 +167,7 @@ struct toshiba_acpi_dev {
unsigned int kbd_illum_supported:1;
unsigned int kbd_led_registered:1;
unsigned int eco_supported:1;
+ unsigned int accelerometer_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -592,6 +598,51 @@ static void toshiba_eco_mode_set_status(struct
led_classdev *cdev,
}
}
+/* Accelerometer support */
+static int toshiba_accelerometer_supported(struct toshiba_acpi_dev *dev)
+{
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ACCELEROMETER2, 0, 0, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ /* Check if the accelerometer call exists,
+* this call also serves as initialization
+*/
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err(ACPI call to query the accelerometer failed\n);
+ return -EIO;
+ } else if (out[0] == DATA_NOT_AVAILABLE || out[0] == NOT_INITIALIZED) {
+ pr_err(Accelerometer not initialized\n);
+ return -EIO;
+ } else if (out[0] == NOT_SUPPORTED) {
+ pr_info(Accelerometer not supported\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int toshiba_accelerometer_get(struct toshiba_acpi_dev *dev,
+ u32 *xy, u32 *z)
+{
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ACCELEROMETER, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ /* Check the Accelerometer status */
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err(ACPI call to query the accelerometer failed\n);
+ return -EIO;
+ }
+
+ *xy = out[2];
+ *z = out[4];
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1195,14 +1246,37 @@ static ssize_t toshiba_kbd_bl_timeout_show(struct
device *dev,
return sprintf(buf, %i\n, time HCI_MISC_SHIFT);
}
+static ssize_t toshiba_position_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 xyval, zval, tmp;
+ u16 x, y, z;
+ int ret;
+
+ xyval = zval = 0;
+ ret = toshiba_accelerometer_get(toshiba, xyval, zval);
+ if (ret 0)
+ return ret;
+
+ x = xyval HCI_ACCEL_MASK;
+ tmp = xyval HCI_MISC_SHIFT;
+ y = tmp HCI_ACCEL_MASK;
+ z = zval HCI_ACCEL_MASK;
+
+ return sprintf(buf, %d %d %d\n, x, y, z);
+}
+
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_backlight_timeout, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_timeout_show, toshiba_kbd_bl_timeout_store);
+static DEVICE_ATTR(position, S_IRUGO, toshiba_position_show, NULL);
static struct attribute *toshiba_attributes[] = {
dev_attr_kbd_backlight_mode.attr,
dev_attr_kbd_backlight_timeout.attr,
+ dev_attr_position.attr,
NULL,
};
@@
[PATCH 8/8] toshiba_acpi: Update version and copyright information
Add myself to the copyright list and bump version to 0.20 since several new features have been added. Signed-off-by: Azael Avalos coproscef...@gmail.com --- drivers/platform/x86/toshiba_acpi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index 0e14e9c..22178f2 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -5,6 +5,7 @@ * Copyright (C) 2002-2004 John Belmonte * Copyright (C) 2008 Philip Langdale * Copyright (C) 2010 Pierre Ducroquet + * Copyright (C) 2013 Azael Avalos * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -37,7 +38,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME : fmt -#define TOSHIBA_ACPI_VERSION 0.19 +#define TOSHIBA_ACPI_VERSION 0.20 #define PROC_INTERFACE_VERSION 1 #include linux/kernel.h -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] toshiba_acpi: Adapt illumination_* code to use the new SCI
Change the toshiba_illumination_* code to use the newly
introduced sci_read and sci_write functions, and in the
process fix toshiba_illumination_available code, since
it was only opening the SCI and the return value was
never checked for errors or actual illumination support.
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_acpi.c | 91 ++---
1 file changed, 33 insertions(+), 58 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 1e580dd..d7ecef3 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -111,6 +111,7 @@ MODULE_LICENSE(GPL);
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
+#define SCI_ILLUMINATION 0x014e
/* field definitions */
#define HCI_HOTKEY_DISABLE 0x0b
@@ -369,18 +370,23 @@ static acpi_status sci_write(struct toshiba_acpi_dev
*dev, u32 reg,
/* Illumination support */
static int toshiba_illumination_available(struct toshiba_acpi_dev *dev)
{
- u32 in[HCI_WORDS] = { 0, 0, 0, 0, 0, 0 };
+ u32 in[TCI_WORDS] = { SCI_GET, SCI_ILLUMINATION, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status;
- in[0] = 0xf100;
+ if (!sci_open(dev))
+ return 0;
+
status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
+ if (ACPI_FAILURE(status) || out[0] == FAILURE) {
+ pr_err(ACPI call to query Illumination support failed\n);
+ return 0;
+ } else if (out[0] == NOT_SUPPORTED || out[1] != 1) {
pr_info(Illumination device not available\n);
return 0;
}
- in[0] = 0xf400;
- status = hci_raw(dev, in, out);
+ sci_close(dev);
+
return 1;
}
@@ -391,43 +397,23 @@ static void toshiba_illumination_set(struct led_classdev
*cdev,
struct toshiba_acpi_dev, led_dev);
u32 in[HCI_WORDS] = { 0, 0, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
+ u32 state, result;
acpi_status status;
- /* First request : initialize communication. */
- in[0] = 0xf100;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info(Illumination device not available\n);
+ if (!sci_open(dev))
return;
- }
- if (brightness) {
- /* Switch the illumination on */
- in[0] = 0xf400;
- in[1] = 0x14e;
- in[2] = 1;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info(ACPI call for illumination failed\n);
- return;
- }
- } else {
- /* Switch the illumination off */
- in[0] = 0xf400;
- in[1] = 0x14e;
- in[2] = 0;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info(ACPI call for illumination failed.\n);
- return;
- }
+ /* Switch the illumination on/off */
+ state = brightness ? 1 : 0;
+ status = sci_write(dev, SCI_ILLUMINATION, state, result);
+ if (ACPI_FAILURE(status)) {
+ pr_err(ACPI call for illumination failed\n);
+ return;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info(Illumination not supported\n);
+ return;
}
-
- /* Last request : close communication. */
- in[0] = 0xf200;
- in[1] = 0;
- in[2] = 0;
- hci_raw(dev, in, out);
+ sci_close(dev);
}
static enum led_brightness toshiba_illumination_get(struct led_classdev *cdev)
@@ -436,35 +422,24 @@ static enum led_brightness
toshiba_illumination_get(struct led_classdev *cdev)
struct toshiba_acpi_dev, led_dev);
u32 in[HCI_WORDS] = { 0, 0, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
+ u32 state, result;
acpi_status status;
- enum led_brightness result;
- /* First request : initialize communication. */
- in[0] = 0xf100;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info(Illumination device not available\n);
+ if (!sci_open(dev))
return LED_OFF;
- }
/* Check the illumination */
- in[0] = 0xf300;
- in[1] = 0x14e;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info(ACPI call for illumination failed.\n);
+ status = sci_read(dev, SCI_ILLUMINATION, state, result);
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err(ACPI call for illumination failed\n);
+ return LED_OFF;
+ } else if (result ==
[PATCH 1/8] toshiba_acpi: Add System Configuration Interface (SCI)
The SCI stands for System Configuration Interface and
it is supposed to be uniform across all their
models.
This patch introduces four new calls, sci_open, sci_close
sci_read and sci_write, along with its definitions and
return codes.
The HCI_ prefix has been removed from all return codes,
since they are shared among the HCI and the SCI.
More information about the SCI can be found at
Jonathan Buzzard's website [1].
[1] http://www.buzzard.me.uk/toshiba/docs.html
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_acpi.c | 146 +++-
1 file changed, 112 insertions(+), 34 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index eb3467e..1e580dd 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -71,27 +71,37 @@ MODULE_LICENSE(GPL);
/* Toshiba ACPI method paths */
#define METHOD_VIDEO_OUT \\_SB_.VALX.DSSX
-/* Toshiba HCI interface definitions
+/* TCI - Toshiba Configuration Interface definitions
*
- * HCI is Toshiba's Hardware Control Interface which is supposed to
- * be uniform across all their models. Ideally we would just call
- * dedicated ACPI methods instead of using this primitive interface.
- * However the ACPI methods seem to be incomplete in some areas (for
- * example they allow setting, but not reading, the LCD brightness value),
+ * This configuration interface is composed by the HCI (Hardware Configuration
+ * Interface) and the SCI (Software Configuration Interface), which are
+ * supposed to be uniform across all their models. Ideally we would just call
+ * dedicated ACPI methods instead of using these primitive interfaces.
+ * However the ACPI methods seem to be incomplete in some areas (for example
+ * they allow setting, but not reading, the LCD brightness value),
* so this is still useful.
*/
#define HCI_WORDS 6
/* operations */
-#define HCI_SET0xff00
+#define SCI_OPEN 0xf100
+#define SCI_CLOSE 0xf200
+#define SCI_GET0xf300
+#define SCI_SET0xf400
#define HCI_GET0xfe00
+#define HCI_SET0xff00
/* return codes */
-#define HCI_SUCCESS0x
-#define HCI_FAILURE0x1000
-#define HCI_NOT_SUPPORTED 0x8000
-#define HCI_EMPTY 0x8c00
+#define SUCCESS0x
+#define OPEN_CLOSE_SUCCESS 0x0044
+#define FAILURE0x1000
+#define NOT_SUPPORTED 0x8000
+#define ALREADY_OPEN 0x8100
+#define NOT_OPENED 0x8200
+#define INPUT_DATA_ERROR 0x8300
+#define NOT_PRESENT0x8600
+#define FIFO_EMPTY 0x8c00
/* registers */
#define HCI_FAN0x0004
@@ -251,7 +261,7 @@ static acpi_status hci_write1(struct toshiba_acpi_dev *dev,
u32 reg,
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
return status;
}
@@ -262,7 +272,7 @@ static acpi_status hci_read1(struct toshiba_acpi_dev *dev,
u32 reg,
u32 out[HCI_WORDS];
acpi_status status = hci_raw(dev, in, out);
*out1 = out[2];
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
return status;
}
@@ -272,7 +282,7 @@ static acpi_status hci_write2(struct toshiba_acpi_dev *dev,
u32 reg,
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
return status;
}
@@ -284,7 +294,75 @@ static acpi_status hci_read2(struct toshiba_acpi_dev *dev,
u32 reg,
acpi_status status = hci_raw(dev, in, out);
*out1 = out[2];
*out2 = out[3];
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
+ return status;
+}
+
+/* common sci tasks
+ */
+
+static int sci_open(struct toshiba_acpi_dev *dev)
+{
+ u32 in[HCI_WORDS] = { SCI_OPEN, 0, 0, 0, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == FAILURE) {
+ pr_err(ACPI call to open SCI failed\n);
+ return 0;
+ }
+
+ if (out[0] == OPEN_CLOSE_SUCCESS) {
+ return 1;
+ } else if (out[0] == ALREADY_OPEN)
[PATCH 4/8] toshiba_acpi: Add kbd backlight support and sysfs files
Toshiba laptops equiped with an illuminated keyboard
can operate in two different modes: Auto and FN-Z.
The Auto mode turns on the led on keystrokes and
automatically turns it off after some (configurable)
time the last key was pressed.
The FN-Z mode is used to toggle the keyboard led on/off
by userspace.
This patch adds support to set the desired KBD mode and
timeout via sysfs, creates and registers toshiba::kbd_backlight
led device whenever the mode is set to FN-Z.
The acceptable values for mode are: 1 (Auto) and 2 (Fn-Z)
The time values range are: 1-60 seconds
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_acpi.c | 242
1 file changed, 242 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 226e0b5..f97f942 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -112,7 +112,9 @@ MODULE_LICENSE(GPL);
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
+#define HCI_KBD_ILLUMINATION 0x0095
#define SCI_ILLUMINATION 0x014e
+#define SCI_KBD_ILLUM_STATUS 0x015c
/* field definitions */
#define HCI_HOTKEY_DISABLE 0x0b
@@ -120,6 +122,7 @@ MODULE_LICENSE(GPL);
#define HCI_LCD_BRIGHTNESS_BITS3
#define HCI_LCD_BRIGHTNESS_SHIFT (16-HCI_LCD_BRIGHTNESS_BITS)
#define HCI_LCD_BRIGHTNESS_LEVELS (1 HCI_LCD_BRIGHTNESS_BITS)
+#define HCI_MISC_SHIFT 0x10
#define HCI_VIDEO_OUT_LCD 0x1
#define HCI_VIDEO_OUT_CRT 0x2
#define HCI_VIDEO_OUT_TV 0x4
@@ -127,6 +130,8 @@ MODULE_LICENSE(GPL);
#define HCI_WIRELESS_BT_PRESENT0x0f
#define HCI_WIRELESS_BT_ATTACH 0x40
#define HCI_WIRELESS_BT_POWER 0x80
+#define SCI_KBD_MODE_FNZ 0x1
+#define SCI_KBD_MODE_AUTO 0x2
struct toshiba_acpi_dev {
struct acpi_device *acpi_dev;
@@ -137,10 +142,13 @@ struct toshiba_acpi_dev {
struct work_struct hotkey_work;
struct backlight_device *backlight_dev;
struct led_classdev led_dev;
+ struct led_classdev kbd_led;
int force_fan;
int last_key_event;
int key_event_valid;
+ int kbd_mode;
+ int kbd_time;
unsigned int illumination_supported:1;
unsigned int video_supported:1;
@@ -149,6 +157,9 @@ struct toshiba_acpi_dev {
unsigned int ntfy_supported:1;
unsigned int info_supported:1;
unsigned int tr_backlight_supported:1;
+ unsigned int kbd_illum_supported:1;
+ unsigned int kbd_led_registered:1;
+ unsigned int sysfs_created:1;
struct mutex mutex;
};
@@ -444,6 +455,89 @@ static enum led_brightness toshiba_illumination_get(struct
led_classdev *cdev)
return state ? LED_FULL : LED_OFF;
}
+/* KBD Illumination */
+static int toshiba_kbd_illum_status_set(struct toshiba_acpi_dev *dev, u32 time)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_write(dev, SCI_KBD_ILLUM_STATUS, time, result);
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err(ACPI call to set KBD backlight status failed\n);
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info(Keyboard backlight status not supported\n);
+ return -ENODEV;
+ }
+ sci_close(dev);
+
+ return 0;
+}
+
+static int toshiba_kbd_illum_status_get(struct toshiba_acpi_dev *dev, u32
*time)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_read(dev, SCI_KBD_ILLUM_STATUS, time, result);
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err(ACPI call to get KBD backlight status failed\n);
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info(Keyboard backlight status not supported\n);
+ return -ENODEV;
+ }
+ sci_close(dev);
+
+ return 0;
+}
+
+static enum led_brightness toshiba_kbd_backlight_get(struct led_classdev *cdev)
+{
+ struct toshiba_acpi_dev *dev = container_of(cdev,
+ struct toshiba_acpi_dev, kbd_led);
+ u32 state, result;
+ acpi_status status;
+
+ /* Check the keyboard backlight state */
+ status = hci_read1(dev, HCI_KBD_ILLUMINATION, state, result);
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err(ACPI call to get the keyboard backlight failed\n);
+ return LED_OFF;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info(Keyboard backlight not supported\n);
+ return LED_OFF;
+ }
+
+
[PATCH 0/8] toshiba_acpi: New features added and a fix
Up for review, the following patch series add new features found on newer Toshiba laptops. The first two fix an illumination detection bug, so consider applying those to stable. The rest just add support for touchpad, accelerometer axes, keyboard backlight and ECO led, plus platform support, bumping the version to 0.20. These apply cleanly to Matthew's platform tree and with just some fuzz to next tree. [PATCH 1/8] toshiba_acpi: Add System Configuration Interface (SCI) [PATCH 2/8] toshiba_acpi: Adapt illumination_* code to use the new SCI [PATCH 3/8] toshiba_acpi: Add platform support [PATCH 4/8] toshiba_acpi: Add kbd backlight support and sysfs files [PATCH 5/8] toshiba_acpi: Add ECO led support [PATCH 6/8] toshiba_acpi: Add accelerometer support [PATCH 7/8] toshiba_acpi: Add touchpad enable/disable support [PATCH 8/8] toshiba_acpi: Update version and copyright information Saludos Azael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/build] x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig
Commit-ID: 7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 Gitweb: http://git.kernel.org/tip/7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 Author: Chen Gang gang.c...@asianux.com AuthorDate: Tue, 5 Nov 2013 09:46:39 +0800 Committer: H. Peter Anvin h...@zytor.com CommitDate: Mon, 4 Nov 2013 20:01:55 -0800 x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig The defconfig kernel can not run under neither fedora16 x86_64 laptop nor fedora17 x86_64 pc. After enable DEVTMPFS* in x86_64_defconfig, it will be OK. DEVTMPFS* is only related with software, so for i386_defconfig may also need them (at least, it has no negative effect for defconfig). Signed-off-by: Chen Gang gang.c...@asianux.com Link: http://lkml.kernel.org/r/52784dff.8040...@asianux.com Signed-off-by: H. Peter Anvin h...@zytor.com --- arch/x86/configs/i386_defconfig | 2 ++ arch/x86/configs/x86_64_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index 9444708..a7fef26 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -142,6 +142,8 @@ CONFIG_MAC80211=y CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_DEBUG_DEVRES=y CONFIG_CONNECTOR=y CONFIG_BLK_DEV_LOOP=y diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index 671524d..c1119d4 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -141,6 +141,8 @@ CONFIG_MAC80211=y CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_DEBUG_DEVRES=y CONFIG_CONNECTOR=y CONFIG_BLK_DEV_LOOP=y -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling in-memory write cache for x86-64 in Linux II
On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote: On Oct 25, 2013, at 2:18 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov t.ar...@lycos.com wrote: On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel built for the i686 (with PAE) and x86-64 architectures. What’s really troubling me is that the x86-64 kernel has the following problem: When I copy large files to any storage device, be it my HDD with ext4 partitions or flash drive with FAT32 partitions, the kernel first caches them in memory entirely then flushes them some time later (quite unpredictably though) or immediately upon invoking sync. Yeah, I think we default to a 10% dirty background memory (and allows up to 20% dirty), so on your 16GB machine, we allow up to 1.6GB of dirty memory for writeout before we even start writing, and twice that before we start *waiting* for it. On 32-bit x86, we only count the memory in the low 1GB (really actually up to about 890MB), so 10% dirty really means just about 90MB of buffering (and a hard limit of ~180MB of dirty). And that up to 3.2GB of dirty memory is just crazy. Our defaults come from the old days of less memory (and perhaps servers that don't much care), and the fact that x86-32 ends up having much lower limits even if you end up having more memory. I think the “delay writes for a long time” is a holdover from the days when e.g. /tmp was on a disk and compilers had lousy IO patterns, then they deleted the file. Today, /tmp is always in RAM, and IMHO the “write and delete” workload tested by dbench is not worthwhile optimizing for. With Lustre, we’ve long taken the approach that if there is enough dirty data on a file to make a decent write (which is around 8MB today even for very fast storage) then there isn’t much point to hold back for more data before starting the IO. Agreed - write-through caching is much better for high throughput streaming data environments than write back caching that can leave the devices unnecessarily idle. However, most systems are not running in high-throughput streaming data environments... :/ Any decent allocator will be able to grow allocated extents to handle following data, or allocate a new extent. At 4-8MB extents, even very seek-impaired media could do 400-800MB/s (likely much faster than the underlying storage anyway). True, but this makes the assumption that the filesystem you are using is optimising purely for write throughput and your storage is not seek limited on reads. That's simply not an assumption we can allow the generic writeback code to make. In more detail, if we simply implement we have 8 MB of dirty pages on a single file, write it we can maximise write throughput by allocating sequentially on disk for each subsquent write. The problem with this comes when you are writing multiple files at a time, and that leads to this pattern on disk: ABC...ABCABCABC And the result is a) fragmented files b) a large number of seeks during sequential read operations and c) filesystems that age and degrade rapidly under workloads that concurrently write files with different life times (i.e. due to free space fragmention). In some situations this is acceptable, but the performance degradation as the filesystem ages that this sort of allocation causes in most environments is not. I'd say that 90% of filesystems out there would suffer accelerated aging as a result of doing writeback in this manner by default. This also avoids wasting (tens of?) seconds of idle disk bandwidth. If the disk is already busy, then the IO will be delayed anyway. If it is not busy, then why aggregate GB of dirty data in memory before flushing it? There are plenty of workloads out there where delaying IO for a few seconds can result in writeback that is an order of magnitude faster. Similarly, I've seen other workloads where the writeback delay results in files that can be *read* orders of magnitude faster Something simple like “start writing at 16MB dirty on a single file” would probably avoid a lot of complexity at little real-world cost. That shouldn’t throttle dirtying memory above 16MB, but just start writeout much earlier than it does today. That doesn't solve the slow device, large file problem. We can write data into the page cache at rates of over a GB/s, so it's irrelevant to a device that can write at 5MB/s whether we start writeback immediately or a second later when there is 500MB of dirty pages in memory. AFAIK, the only way to avoid that problem is to use write-through caching for such devices - where they throttle to the IO rate at very low levels of cached data. Realistically, there is no one right answer for all combinations of applications, filesystems and hardware, but writeback caching is the best *general solution* we've got right now. However, IMO users should
Re: [tip:x86/build] x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig
On 11/05/2013 12:03 PM, tip-bot for Chen Gang wrote: Commit-ID: 7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 Gitweb: http://git.kernel.org/tip/7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 Author: Chen Gang gang.c...@asianux.com AuthorDate: Tue, 5 Nov 2013 09:46:39 +0800 Committer: H. Peter Anvin h...@zytor.com CommitDate: Mon, 4 Nov 2013 20:01:55 -0800 x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig The defconfig kernel can not run under neither fedora16 x86_64 laptop nor fedora17 x86_64 pc. After enable DEVTMPFS* in x86_64_defconfig, it will be OK. DEVTMPFS* is only related with software, so for i386_defconfig may also need them (at least, it has no negative effect for defconfig). Signed-off-by: Chen Gang gang.c...@asianux.com Link: http://lkml.kernel.org/r/52784dff.8040...@asianux.com Signed-off-by: H. Peter Anvin h...@zytor.com Thanks. -- Chen Gang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] cpufreq: cpufreq-cpu0: use the max voltage instead of voltage-tolerance
Adding shawn in cc list..
On 5 November 2013 08:40, rjying rjy...@gmail.com wrote:
From: Rongjun Ying rongjun.y...@csr.com
Sometime the regulator can't supply appropriate voltages for requestion of
cpu.
All voltage tolerance value can't figure out a good voltage.
Signed-off-by: Rongjun Ying rongjun.y...@csr.com
---
drivers/cpufreq/cpufreq-cpu0.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index c522a95..0c9e6b9 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -23,7 +23,7 @@
#include linux/slab.h
static unsigned int transition_latency;
-static unsigned int voltage_tolerance; /* in percentage */
+static unsigned int voltage_max;
static struct device *cpu_dev;
static struct clk *cpu_clk;
@@ -45,7 +45,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
{
struct cpufreq_freqs freqs;
struct opp *opp;
- unsigned long volt = 0, volt_old = 0, tol = 0;
+ unsigned long volt = 0, volt_old = 0;
long freq_Hz, freq_exact;
unsigned int index;
int ret;
@@ -82,7 +82,6 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
}
volt = opp_get_voltage(opp);
rcu_read_unlock();
- tol = volt * voltage_tolerance / 100;
volt_old = regulator_get_voltage(cpu_reg);
}
@@ -92,7 +91,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
/* scaling up? scale voltage before frequency */
if (!IS_ERR(cpu_reg) freqs.new freqs.old) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
if (ret) {
pr_err(failed to scale voltage up: %d\n, ret);
freqs.new = freqs.old;
@@ -104,14 +103,14 @@ static int cpu0_set_target(struct cpufreq_policy
*policy,
if (ret) {
pr_err(failed to set clock rate: %d\n, ret);
if (!IS_ERR(cpu_reg))
- regulator_set_voltage_tol(cpu_reg, volt_old, tol);
+ regulator_set_voltage(cpu_reg, volt_old, voltage_max);
freqs.new = freqs.old;
goto post_notify;
}
/* scaling down? scale voltage after frequency */
if (!IS_ERR(cpu_reg) freqs.new freqs.old) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
if (ret) {
pr_err(failed to scale voltage down: %d\n, ret);
clk_set_rate(cpu_clk, freqs.old * 1000);
@@ -224,7 +223,11 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
goto out_put_node;
}
- of_property_read_u32(np, voltage-tolerance, voltage_tolerance);
+ ret = of_property_read_u32(np, voltage-max, voltage_max);
+ if (ret) {
+ pr_err(failed to get max voltage: %d\n, ret);
+ goto out_put_node;
+ }
if (of_property_read_u32(np, clock-latency, transition_latency))
transition_latency = CPUFREQ_ETERNAL;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] tools/perf/build: Fix detection of non-core features
ping. did not see this one in your last push to Ingo. On 10/29/13, 10:43 AM, David Ahern wrote: feature_check needs to be invoked through call, and LDFLAGS may not be set so quotes are needed. Thanks to Jiri for spotting the quotes around LDFLAGS; that one was driving me nuts with the upcoming timerfd feature detection. Signed-off-by: David Ahern dsah...@gmail.com Cc: Ingo Molnar mi...@kernel.org Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Namhyung Kim namhy...@kernel.org Cc: Jiri Olsa jo...@redhat.com --- tools/perf/config/Makefile | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 543aa953bab1..c82772207e6e 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -96,7 +96,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 /dev/null 2/dev/null echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 /dev/null 2/dev/null echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) @@ -233,7 +233,7 @@ CFLAGS += -I$(LIB_INCLUDE) CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE ifndef NO_BIONIC - $(feature_check,bionic) + $(call feature_check,bionic) ifeq ($(feature-bionic), 1) BIONIC := 1 EXTLIBS := $(filter-out -lrt,$(EXTLIBS)) @@ -470,15 +470,15 @@ else CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT else ifneq ($(feature-libbfd), 1) - $(feature_check,liberty) + $(call feature_check,liberty) ifeq ($(feature-liberty), 1) EXTLIBS += -lbfd -liberty else -$(feature_check,liberty-z) +$(call feature_check,liberty-z) ifeq ($(feature-liberty-z), 1) EXTLIBS += -lbfd -liberty -lz else - $(feature_check,cplus-demangle) + $(call feature_check,cplus-demangle) ifeq ($(feature-cplus-demangle), 1) EXTLIBS += -liberty CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf kvm: Disable live command if timerfd is not supported
ditto
On 10/29/13, 10:43 AM, David Ahern wrote:
If the OS does not have timerfd support (e.g., older OS'es like RHEL5)
disable perf kvm stat live.
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Namhyung Kim namhy...@kernel.org
Cc: Jiri Olsa jo...@redhat.com
---
tools/perf/builtin-kvm.c| 12
tools/perf/config/Makefile | 7 +++
tools/perf/config/feature-checks/Makefile | 6 +-
tools/perf/config/feature-checks/test-all.c | 5 +
tools/perf/config/feature-checks/test-timerfd.c | 18 ++
5 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/config/feature-checks/test-timerfd.c
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index cb05f39d8a77..cd9f92078aba 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -20,7 +20,9 @@
#include util/data.h
#include sys/prctl.h
+#ifdef HAVE_TIMERFD_SUPPORT
#include sys/timerfd.h
+#endif
#include termios.h
#include semaphore.h
@@ -337,6 +339,7 @@ static void init_kvm_event_record(struct perf_kvm_stat *kvm)
INIT_LIST_HEAD(kvm-kvm_events_cache[i]);
}
+#ifdef HAVE_TIMERFD_SUPPORT
static void clear_events_cache_stats(struct list_head *kvm_events_cache)
{
struct list_head *head;
@@ -358,6 +361,7 @@ static void clear_events_cache_stats(struct list_head
*kvm_events_cache)
}
}
}
+#endif
static int kvm_events_hash_fn(u64 key)
{
@@ -783,6 +787,7 @@ static void print_result(struct perf_kvm_stat *kvm)
pr_info(\nLost events: % PRIu64 \n\n, kvm-lost_events);
}
+#ifdef HAVE_TIMERFD_SUPPORT
static int process_lost_event(struct perf_tool *tool,
union perf_event *event __maybe_unused,
struct perf_sample *sample __maybe_unused,
@@ -793,6 +798,7 @@ static int process_lost_event(struct perf_tool *tool,
kvm-lost_events++;
return 0;
}
+#endif
static bool skip_sample(struct perf_kvm_stat *kvm,
struct perf_sample *sample)
@@ -872,6 +878,7 @@ static bool verify_vcpu(int vcpu)
return true;
}
+#ifdef HAVE_TIMERFD_SUPPORT
/* keeping the max events to a modest level to keep
* the processing of samples per mmap smooth.
*/
@@ -1213,6 +1220,7 @@ static int kvm_live_open_events(struct perf_kvm_stat *kvm)
out:
return rc;
}
+#endif
static int read_events(struct perf_kvm_stat *kvm)
{
@@ -1379,6 +1387,7 @@ kvm_events_report(struct perf_kvm_stat *kvm, int argc,
const char **argv)
return kvm_events_report_vcpu(kvm);
}
+#ifdef HAVE_TIMERFD_SUPPORT
static struct perf_evlist *kvm_live_event_list(void)
{
struct perf_evlist *evlist;
@@ -1566,6 +1575,7 @@ out:
return err;
}
+#endif
static void print_kvm_stat_usage(void)
{
@@ -1604,8 +1614,10 @@ static int kvm_cmd_stat(const char *file_name, int argc,
const char **argv)
if (!strncmp(argv[1], rep, 3))
return kvm_events_report(kvm, argc - 1 , argv + 1);
+#ifdef HAVE_TIMERFD_SUPPORT
if (!strncmp(argv[1], live, 4))
return kvm_events_live(kvm, argc - 1 , argv + 1);
+#endif
perf_stat:
return cmd_stat(argc, argv, NULL);
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index c82772207e6e..afe4945e3e84 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -395,6 +395,13 @@ else
endif
endif
+$(call feature_check,timerfd)
+ifeq ($(feature-timerfd), 1)
+ CFLAGS += -DHAVE_TIMERFD_SUPPORT
+else
+ msg := $(warning No timerfd support. Disables 'perf kvm stat live');
+endif
+
disable-python = $(eval $(disable-python_code))
define disable-python_code
CFLAGS += -DNO_LIBPYTHON
diff --git a/tools/perf/config/feature-checks/Makefile
b/tools/perf/config/feature-checks/Makefile
index 452b67cc4d7b..a4d4173c576e 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -25,7 +25,8 @@ FILES=\
test-libunwind \
test-on-exit\
test-stackprotector-all \
- test-stackprotector
+ test-stackprotector \
+ test-timerfd
CC := $(CC) -MD
@@ -136,6 +137,9 @@ test-on-exit:
test-backtrace:
$(BUILD)
+test-timerfd:
+ $(BUILD)
+
-include *.d
###
diff --git a/tools/perf/config/feature-checks/test-all.c
b/tools/perf/config/feature-checks/test-all.c
index 50d431892a0c..59e7a705e146 100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@ -81,6 +81,10 @@
# include test-libnuma.c
#undef main
+#define main main_test_timerfd
+# include test-timerfd.c
+#undef main
+
int main(int argc, char
Re: Linux 3.12 released .. and 4.0 plans?
Jan Engelhardt wrote: On Monday 2013-11-04 01:10, Linus Torvalds wrote: Onto a totally different topic: we're getting to release numbers where I have to take off my socks to count that high again. I'm ok with 3.low teens [...] [4.0 ok, after 3.19 (or whatever),] What would you do when the major number becomes such an unpleasant highteen number? (That will be in ~64 years if you wrap after x.19.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I guess renaming the kernel would be an option. (Linus would be ~106 years old by the way.) -- Aldo Iljazi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12 released .. and 4.0 plans?
Am 04.11.2013 22:46, schrieb Jan Engelhardt: On Monday 2013-11-04 01:10, Linus Torvalds wrote: Onto a totally different topic: we're getting to release numbers where I have to take off my socks to count that high again. I'm ok with 3.low teens [...] [4.0 ok, after 3.19 (or whatever),] What would you do when the major number becomes such an unpleasant highteen number? (That will be in ~64 years if you wrap after x.19.) Changing the counting base and going hex would offer some more years. So after 9.19 he could switch to a.0 instead of 10.0. Or just call it then LinuxNG and start with 1.0 again. But to add something serious to the discussion too, I don't see a reason why to make a bugfix-only version. There should be no need to spend a version number for a bugfix only time. E.g. just insert a bugfix-only time (handled like times at -rc7) before a merge window for a new version. That would give people the possibility to get their bugfix-patches into mainline in order to get them into the stable series without the need to spend a version number. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the staging tree with the block tree
Hi Greg, Today's linux-next merge of the staging tree got a conflict in drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265 (block: Abstract out bvec iterator) from the block tree and commit de40d1209898 (staging: lustre: fix bug with LL_MRF_RETURN in loop_make_request) from the staging tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/staging/lustre/lustre/llite/lloop.c index 3488bb6c44a7,e2421ea61352.. --- a/drivers/staging/lustre/lustre/llite/lloop.c +++ b/drivers/staging/lustre/lustre/llite/lloop.c @@@ -368,10 -365,9 +367,9 @@@ static void loop_make_request(struct re goto err; } loop_add_bio(lo, old_bio); - LL_MRF_RETURN(0); + return; err: - cfs_bio_io_error(old_bio, old_bio-bi_size); + cfs_bio_io_error(old_bio, old_bio-bi_iter.bi_size); - LL_MRF_RETURN(0); } pgpdDLQfbmLDS.pgp Description: PGP signature
Re: linux-next: manual merge of the staging tree with the block tree
On Tue, Nov 05, 2013 at 04:09:24PM +1100, Stephen Rothwell wrote: Hi Greg, Today's linux-next merge of the staging tree got a conflict in drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265 (block: Abstract out bvec iterator) from the block tree and commit de40d1209898 (staging: lustre: fix bug with LL_MRF_RETURN in loop_make_request) from the staging tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Looks good to me, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote: But after I let it pure next-20131101 (git reset HEAD^; git stash), it still cause this issue. It's also because: Also, there's a defect in function vcs_find_signers. It should only return the commit count and array references. If there are no signers in the commit history interval specified, then the authors array is added to the signers array and returned as a single array. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Attn.......
-- Good day, I am Mr. Cham Tao Soon, Chairman Audit Committee of UOB Bank, Singapore. I have a project for you in the tons of One Hundred Five Million EUR, after successful transfer, we shall share in the ratio of forty for you and sixty for me. Please reply for specifics. Yours, Mr. Cham Tao Soon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the bcon tree
Hi Jörn, After merging the bcon tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/block/blockconsole.c: In function 'sync_read': drivers/block/blockconsole.c:184:5: error: 'struct bio' has no member named 'bi_idx' bio.bi_idx = 0; ^ drivers/block/blockconsole.c:185:5: error: 'struct bio' has no member named 'bi_size' bio.bi_size = SECTOR_SIZE; ^ drivers/block/blockconsole.c:187:5: error: 'struct bio' has no member named 'bi_sector' bio.bi_sector = ofs SECTOR_SHIFT; ^ drivers/block/blockconsole.c: In function 'bcon_erase_segment': drivers/block/blockconsole.c:215:6: error: 'struct bio' has no member named 'bi_size' bio-bi_size = PAGE_SIZE; ^ drivers/block/blockconsole.c:218:6: error: 'struct bio' has no member named 'bi_idx' bio-bi_idx = 0; ^ drivers/block/blockconsole.c:219:6: error: 'struct bio' has no member named 'bi_sector' bio-bi_sector = (bc-write_bytes + i * PAGE_SIZE) 9; ^ drivers/block/blockconsole.c: In function 'bcon_writesector': drivers/block/blockconsole.c:338:5: error: 'struct bio' has no member named 'bi_size' bio-bi_size = SECTOR_SIZE; ^ drivers/block/blockconsole.c:343:5: error: 'struct bio' has no member named 'bi_idx' bio-bi_idx = 0; ^ drivers/block/blockconsole.c:344:5: error: 'struct bio' has no member named 'bi_sector' bio-bi_sector = bc-write_bytes 9; ^ Caused by changes in the block tree. Thierry Reding mentioned that you didn't think that the bcon tree was linux-next material any more, so I just dropped your tree. If that is incorrect, please let me know and I will reinstate it and fix this merge conflict. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpvlDXdyWcUe.pgp Description: PGP signature
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On 11/05/2013 01:23 PM, Joe Perches wrote: On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote: But after I let it pure next-20131101 (git reset HEAD^; git stash), it still cause this issue. It's also because: Also, there's a defect in function vcs_find_signers. It should only return the commit count and array references. If there are no signers in the commit history interval specified, then the authors array is added to the signers array and returned as a single array. OK, thanks. Do you mean: in pure next-20131101 contents an author which commit a patch, but not signed himself? (if so, it seems the related patch need be re-committed again by the related author). Thanks. -- Chen Gang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On 11/05/2013 01:42 PM, Chen Gang wrote: On 11/05/2013 01:23 PM, Joe Perches wrote: On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote: But after I let it pure next-20131101 (git reset HEAD^; git stash), it still cause this issue. It's also because: Also, there's a defect in function vcs_find_signers. It should only return the commit count and array references. If there are no signers in the commit history interval specified, then the authors array is added to the signers array and returned as a single array. OK, thanks. Do you mean: in pure next-20131101 contents an author which commit a patch, but not signed himself? (if so, it seems the related patch need be re-committed again by the related author). If really as what I guess above (some patches no Signed-of-by), is there a tool to check and find this issue in time? Thanks. -- Chen Gang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On Tue, 2013-11-05 at 13:42 +0800, Chen Gang wrote: On 11/05/2013 01:23 PM, Joe Perches wrote: On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote: But after I let it pure next-20131101 (git reset HEAD^; git stash), it still cause this issue. It's also because: Also, there's a defect in function vcs_find_signers. It should only return the commit count and array references. If there are no signers in the commit history interval specified, then the authors array is added to the signers array and returned as a single array. OK, thanks. Do you mean: in pure next-20131101 contents an author which commit a patch, but not signed himself? Yes, I mean that. (if so, it seems the related patch need be re-committed again by the related author). No it doesn't mean that. Prior to this patch, get_maintainer only used sign-off-by style lines to find interested parties to send patches to when the MAINTAINERS file did not have a specific section entry with a matching file pattern to the files that that the patch modified. And there was a defect in the script when no commit history at all was found for the files modified during the period selected (1 year of git log history by default) Now, using this newly modified get_maintainer.pl script, the commit authors shown in the git log history as well as the commit signers are selected. If there is no git history, the script defect is also fixed. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On Tue, 2013-11-05 at 13:45 +0800, Chen Gang wrote: If really as what I guess above (some patches no Signed-of-by), is there a tool to check and find this issue in time? scripts/checkpatch.pl bleats a message on missing sign-offs. For instance: $ cat cache.diff include/linux/cache.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/cache.h b/include/linux/cache.h index 4c57065..17e7e82 100644 --- a/include/linux/cache.h +++ b/include/linux/cache.h @@ -1,11 +1,11 @@ #ifndef __LINUX_CACHE_H #define __LINUX_CACHE_H -#include linux/kernel.h +#include uapi/linux/kernel.h #include asm/cache.h #ifndef L1_CACHE_ALIGN -#define L1_CACHE_ALIGN(x) ALIGN(x, L1_CACHE_BYTES) +#define L1_CACHE_ALIGN(x) __ALIGN_KERNEL(x, L1_CACHE_BYTES) #endif #ifndef SMP_CACHE_BYTES $ ./scripts/checkpatch.pl cache.diff ERROR: Missing Signed-off-by: line(s) total: 1 errors, 0 warnings, 13 lines checked cache.diff has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On 11/05/2013 01:50 PM, Joe Perches wrote: On Tue, 2013-11-05 at 13:42 +0800, Chen Gang wrote: On 11/05/2013 01:23 PM, Joe Perches wrote: On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote: (if so, it seems the related patch need be re-committed again by the related author). No it doesn't mean that. Prior to this patch, get_maintainer only used sign-off-by style lines to find interested parties to send patches to when the MAINTAINERS file did not have a specific section entry with a matching file pattern to the files that that the patch modified. And there was a defect in the script when no commit history at all was found for the files modified during the period selected (1 year of git log history by default) Now, using this newly modified get_maintainer.pl script, the commit authors shown in the git log history as well as the commit signers are selected. If there is no git history, the script defect is also fixed. Yeah, our get_maintainer.pl need be smart enough to bear it (this patch let our get_maintainer.pl smart enough). But for this kind of patch, need it re-commit again? (for me, I recommend to re-commit it again by the related author). Thanks. -- Chen Gang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On 11/05/2013 01:54 PM, Joe Perches wrote: On Tue, 2013-11-05 at 13:45 +0800, Chen Gang wrote: If really as what I guess above (some patches no Signed-of-by), is there a tool to check and find this issue in time? scripts/checkpatch.pl bleats a message on missing sign-offs. Yeah, the author/maintainer can use it for checking. But do we have additional tools to let the version tree integrator (e.g. sfr) notice about it? Thanks. -- Chen Gang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
* Steven Rostedt rost...@goodmis.org wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and kernel will
reboot.
This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Borislav Petkov b...@suse.de
Cc: Ingo Molnar mi...@kernel.org
---
kernel/extable.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/extable.c b/kernel/extable.c
index 832cb28..022fb25 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
* pointer is part of the kernel text, we need to do some
* special dereferencing first.
*/
-int func_ptr_is_kernel_text(void *ptr)
+int nokprobe func_ptr_is_kernel_text(void *ptr)
{
unsigned long addr;
addr = (unsigned long) dereference_function_descriptor(ptr);
One thing I worry about the nokprobe annotation, is that it moves the
location of the function out of local. This function no exists in the
section with its users. Same with the debug functions in the other
patch.
Well, it's a bit like noinline, that changes the position of the function
as well. So it's not true that 'noxyz' attributes don't affect function
placement - they often don't, but some do.
The more important aspect is that 'noprobe' makes it really, really
apparent what the tag is about, at first sight.
_How_ the 'non probing' is achived is an implementational detail when
kprobes are enabled: right now it puts a function into a separate section,
but we could just a much build a list of function names and check against
it at probe insertion time.
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve Author: rolestats
On Tue, 2013-11-05 at 14:04 +0800, Chen Gang wrote: On 11/05/2013 01:54 PM, Joe Perches wrote: On Tue, 2013-11-05 at 13:45 +0800, Chen Gang wrote: If really as what I guess above (some patches no Signed-of-by), is there a tool to check and find this issue in time? scripts/checkpatch.pl bleats a message on missing sign-offs. Yeah, the author/maintainer can use it for checking. But do we have additional tools to let the version tree integrator (e.g. sfr) notice about it? git pre-commit hooks work. btw: there's some development efforts going on that might help here eventually. Read this thread: https://lkml.org/lkml/2013/10/26/158 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Allow NR_CPUS=1024
* H. Peter Anvin h...@zytor.com wrote: On 11/04/2013 12:11 PM, Ingo Molnar wrote: * H. Peter Anvin h...@zytor.com wrote: 8192 maybe? Yeah, that makes more sense I guess. However, I still have serious issues with crap like this because randconfig is basically broken. If nothing else we need to get that feedback to the kconfig maintainers. The problem with that is that there are no kconfig maintainers: KCONFIG ... S: Odd Fixes The kconfig code is still a hard to maintain, scarcely documented mess. It took us almost a decade to rescue the NTP code from a similar obfuscation trap and make it maintainable. It had the same author as the original Kconfig code - and the Kconfig code is 10 times larger than the NTP code. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
