| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20140319133653.GZ25953@redhat.com>
Date: Wed, 19 Mar 2014 09:36:53 -0400
From: Don Zickus <dzickus@...hat.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: acme@...stprotocols.net, LKML <linux-kernel@...r.kernel.org>,
jmario@...hat.com, fowles@...each.com, eranian@...gle.com
Subject: Re: [PATCH 02/19] perf, sort: Add physid sorting based on mmap2 data
On Wed, Mar 19, 2014 at 11:45:15AM +0100, Jiri Olsa wrote:
> > +static int64_t
> > +sort__physid_cmp(struct hist_entry *left, struct hist_entry *right)
> > +{
> > + u64 l, r;
> > + struct map *l_map = left->mem_info->daddr.map;
> > + struct map *r_map = right->mem_info->daddr.map;
> > +
> > + /* store all NULL mem maps at the bottom */
> > + /* shouldn't even need this check, should have stubs */
> > + if (!left->mem_info->daddr.map || !right->mem_info->daddr.map)
> > + return 1;
> > +
> > + /* group event types together */
> > + if (left->cpumode > right->cpumode) return -1;
> > + if (left->cpumode < right->cpumode) return 1;
> > +
> > + if (l_map->maj > r_map->maj) return -1;
> > + if (l_map->maj < r_map->maj) return 1;
> > +
> > + if (l_map->min > r_map->min) return -1;
> > + if (l_map->min < r_map->min) return 1;
> > +
> > + if (l_map->ino > r_map->ino) return -1;
> > + if (l_map->ino < r_map->ino) return 1;
> > +
> > + if (l_map->ino_generation > r_map->ino_generation) return -1;
> > + if (l_map->ino_generation < r_map->ino_generation) return 1;
> > +
> > + /*
> > + * Addresses with no major/minor numbers are assumed to be
> > + * anonymous in userspace. Sort those on pid then address.
> > + *
> > + * The kernel and non-zero major/minor mapped areas are
> > + * assumed to be unity mapped. Sort those on address then pid.
> > + */
> > +
> > + /* al_addr does all the right addr - start + offset calculations */
> > + l = left->mem_info->daddr.al_addr;
> > + r = right->mem_info->daddr.al_addr;
> > +
> > + if (l_map->maj || l_map->min || l_map->ino || l_map-> ino_generation) {
> > + /* mmapped areas */
> > +
> > + /* hack to mark similar regions, 'right' is new entry */
> > + /* entries with same maj/min/ino/inogen are in same address space */
> > + right->color = TRUE;
> > +
> > + if (l > r) return -1;
> > + if (l < r) return 1;
> > +
> > + /* sorting by iaddr makes calculations easier later */
> > + if (left->mem_info->iaddr.al_addr > right->mem_info->iaddr.al_addr) return -1;
> > + if (left->mem_info->iaddr.al_addr < right->mem_info->iaddr.al_addr) return 1;
> > +
> > + if (left->thread->pid_ > right->thread->pid_) return -1;
> > + if (left->thread->pid_ < right->thread->pid_) return 1;
> > +
> > + if (left->thread->tid > right->thread->tid) return -1;
> > + if (left->thread->tid < right->thread->tid) return 1;
> > + } else if (left->cpumode == PERF_RECORD_MISC_KERNEL) {
> > + /* kernel mapped areas where 'start' doesn't matter */
> > +
> > + /* hack to mark similar regions, 'right' is new entry */
> > + /* whole kernel region is in the same address space */
> > + right->color = TRUE;
> > +
> > + if (l > r) return -1;
> > + if (l < r) return 1;
> > +
> > + /* sorting by iaddr makes calculations easier later */
> > + if (left->mem_info->iaddr.al_addr > right->mem_info->iaddr.al_addr) return -1;
> > + if (left->mem_info->iaddr.al_addr < right->mem_info->iaddr.al_addr) return 1;
> > +
> > + if (left->thread->pid_ > right->thread->pid_) return -1;
> > + if (left->thread->pid_ < right->thread->pid_) return 1;
> > +
> > + if (left->thread->tid > right->thread->tid) return -1;
> > + if (left->thread->tid < right->thread->tid) return 1;
> > + } else {
> > + /* userspace anonymous */
> > + if (left->thread->pid_ > right->thread->pid_) return -1;
> > + if (left->thread->pid_ < right->thread->pid_) return 1;
> > +
> > + if (left->thread->tid > right->thread->tid) return -1;
> > + if (left->thread->tid < right->thread->tid) return 1;
> > +
> > + /* hack to mark similar regions, 'right' is new entry */
> > + /* userspace anonymous address space is contained within pid */
> > + right->color = TRUE;
> > +
> > + if (l > r) return -1;
> > + if (l < r) return 1;
> > +
> > + /* sorting by iaddr makes calculations easier later */
> > + if (left->mem_info->iaddr.al_addr > right->mem_info->iaddr.al_addr) return -1;
> > + if (left->mem_info->iaddr.al_addr < right->mem_info->iaddr.al_addr) return 1;
> > + }
>
> do you need single column for 'physid' ?
>
> my first idea was to have separate sort entries for all checked entries:
> (same way like for memory memory_sort_dimensions)
>
> - mem_info->daddr.al_addr (we already have 'addr' check)
> - mem_info->iaddr.al_addr
> - thread->pid_ (we have only 'tid' check so far)
> - l_map->maj, l_map->min, l_map->ino, l_map, ino_generation (we could probably group these)
>
> and init sort order with:
>
> sort_order = "physid,pid,...";
>
> '...' is whatever name you choose for above entries
The problem is (as you can see in the code above), physid is _not_ just
one piece of data. It is dependent on multiple things. It is mainly
dependent on four things:
- cpumode
- major, minor, inode, inode_generation (call it mmap2 data)
- data address
- pid
If cpumode == KERNEL, sort in this order
- mmap2 data
- data address
- pid (optional)
If cpumode == USERSPACE and mmap2 data != 0, sort in this order
- mmap2 data
- data address
- pid (optional)
If cpumode == USERSAPCE and mmap2 data == 0, sort in this order
- pid
- data address
Notice how sorting on the pid is different depending on the scenario.
I'll agree that sorting on iaddr and tid can be filtered out as a nice to
have.
But in order to sort on physid, you really need lots of pieces.
Otherwise, what do you consider the definition of 'physid'? :-)
Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists