feature-removal-schedule entry from 2009

DISCUSSION Rob Landley 3 participants 7 messages Jul 12, 2012 – Jul 17, 2012 User-mode Linux (UML)

Share & tools

Rob Landley

author

2012-07-12 00:52 UTC #0 lore raw

IRQF_SAMPLE_RANDOM is 3 years past its sell-by date in feature-removal-schedule:

What:   IRQF_SAMPLE_RANDOM
Check:  IRQF_SAMPLE_RANDOM
When:   July 2009

Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as
entropy sources in the kernel's current entropy model. To resolve this, every input point to the kernel's entropy pool needs to better document the type of entropy source it actually is. This will be replaced with additional add_*_randomness functions in drivers/char/random.c

Who: Robin Getz <[email protected]>
& Matt Mackall <[email protected]>

There are 12 remaining uses under drivers/ and 14 more under arch/, the rest of the hits look like infrastructure implementing it.

Should I run those files through bother-maintainer.pl and try to get people to stop it, or is there a plan underway I don't know about?

Rob

Signature · 2 lines

GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

Theodore Ts'o

2012-07-13 03:03 UTC #1 lore raw

Quoted 14 lines · Rob Landley

IRQF_SAMPLE_RANDOM is 3 years past its sell-by date in feature-removal-schedule:
What:   IRQF_SAMPLE_RANDOM
Check:  IRQF_SAMPLE_RANDOM
When:   July 2009
Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as
entropy sources in the kernel's current entropy model. To resolve this, every input point to the kernel's entropy pool needs to better document the type of entropy source it actually is. This will be replaced with additional add_*_randomness functions in drivers/char/random.c

Quoted 8 lines

Who: Robin Getz <[email protected]>
& Matt Mackall <[email protected]>
There are 12 remaining uses under drivers/ and 14 more under arch/, the rest of the hits look like infrastructure implementing it.
Should I run those files through bother-maintainer.pl and try to get people to stop it, or is there a plan underway I don't know about?

I was going to deal with that in the new /dev/random tree; once those changes go in, IRQF_SAMPLE_RANDOM effectively becomes a no-op. But I'd prefer that the ordering be that we get the new sample_interrupt_randomness() changes in first, and then remove the IRQF_SAMPLE_RANDOM.

I've just been slammed with work, processing patches for the ext4 merge window, and kernel summit planning, and quite frankly, I considered this to be relatively low priority --- especially since we no shortage of IRQF_* flag bits, and once the new sample_interrupt_randomness() goes in, the flag is a complete no-op.

- Ted

Rob Landley

author

2012-07-16 03:41 UTC #2 lore raw

Quoted 4 lines · Theodore Ts'o

Quoted 3 lines · Rob Landley
There are 12 remaining uses under drivers/ and 14 more under arch/, the rest of the hits look like infrastructure implementing it.

Quoted 8 lines

Quoted 2 lines
Should I run those files through bother-maintainer.pl and try to get people to stop it, or is there a plan underway I don't know about?
I was going to deal with that in the new /dev/random tree; once those changes go in, IRQF_SAMPLE_RANDOM effectively becomes a no-op. But I'd prefer that the ordering be that we get the new sample_interrupt_randomness() changes in first, and then remove the IRQF_SAMPLE_RANDOM.

Does it become a "please add a call to sample_interrupt_randomness()" reminder, or will the infrastructure figure out when to do that outside the driver?

And will this upcoming patch set remove 'em, or leave the NOP debris there?

Quoted 1 line

I've just been slammed with work,

I know the feeling. At my day job we work with such a "will never see the light of day" kernel that my open source stuff is strictly recreational, hence catching up with email on the weekend...

(How this can be license compliant: start with an obsolete version recently _upgraded_ to 2.6.37, then the android fork off of that, then the TI fork off of android, then our local fork off of TI. I'm sure the hardware we eventually ship will get a technically compliant corresponding source tarball snapshot sans repository history posted _somewhere_, but nobody will ever care.)

Quoted 5 lines

processing patches for the ext4
merge window, and kernel summit planning, and quite frankly, I considered this to be relatively low priority --- especially since we no shortage of IRQF_* flag bits, and once the new sample_interrupt_randomness() goes in, the flag is a complete no-op.

Sure, I'm just bussing tables and asking "you done with that". I only poke 'cuz it's been 3 years.

Quoted 1 line

- Ted

Rob

Signature · 2 lines

GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

Theodore Ts'o

2012-07-16 15:21 UTC #3 lore raw

Quoted 3 lines · Rob Landley

Does it become a "please add a call to sample_interrupt_randomness()" reminder, or will the infrastructure figure out when to do that outside the driver?

The patches in the random.git tree unconditionally call add_interrupt_randomness() in handle_irq_event_percpu(), so the drivers don't need to do anything at this point.

Quoted 2 lines

And will this upcoming patch set remove 'em, or leave the NOP debris there?

The current status is here:

http://git.kernel.org/?p=linux/kernel/git/tytso/random.git;a=summary

At this point the flag is a no-op, and can be removed. This close to the merge window, I don't think I'm going to have time to create patches which remove the flag from all of the drivers, but it's basically clean up work, and having the extra bit set isn't going to harm anyone.

The only thing that might require a bit of care is the usage in arch/um, where someone needs to do a bit more analysis to see if it's just a matter of removing the flag from the call to request_irq(). My current thinking was to merge the new interrupt structure during this merge window, and then clean up the NOP debris during the next development cycle.

- Ted

Rob Landley

author

2012-07-17 17:19 UTC #4 lore raw

That should be over on _this_ list then...

(Discussion of IRQF_SAMPLE_RANDOM removal.)

Quoted 22 lines · Theodore Ts'o

Quoted 3 lines · Rob Landley
Does it become a "please add a call to sample_interrupt_randomness()" reminder, or will the infrastructure figure out when to do that outside the driver?
The patches in the random.git tree unconditionally call add_interrupt_randomness() in handle_irq_event_percpu(), so the drivers don't need to do anything at this point.
Quoted 2 lines
And will this upcoming patch set remove 'em, or leave the NOP debris there?
The current status is here:
http://git.kernel.org/?p=linux/kernel/git/tytso/random.git;a=summary
At this point the flag is a no-op, and can be removed. This close to the merge window, I don't think I'm going to have time to create patches which remove the flag from all of the drivers, but it's basically clean up work, and having the extra bit set isn't going to harm anyone.

Quoted 10 lines

The only thing that might require a bit of care is the usage in arch/um, where someone needs to do a bit more analysis to see if it's just a matter of removing the flag from the call to request_irq(). My current thinking was to merge the new interrupt structure during this merge window, and then clean up the NOP debris during the next development cycle.
- Ted

Rob

Signature · 13 lines

GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Theodore Ts'o

2012-07-17 21:59 UTC #5 lore raw

Quoted 3 lines · Rob Landley

That should be over on _this_ list then...
(Discussion of IRQF_SAMPLE_RANDOM removal.)

I took a closer look at the arch/um code, and it wasn't as hard as I thought. I have a proposed set of patches to completely remove IRQF_SAMPLE_RANDOM that I will be sending out shortly....

- Ted

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Richard Weinberger

maintainer

2012-07-17 22:30 UTC #6 lore raw

Am Tue, 17 Jul 2012 17:29:46 -0400
schrieb Theodore Ts'o <[email protected]>:

Quoted 9 lines · Rob Landley

Quoted 3 lines
That should be over on _this_ list then...
(Discussion of IRQF_SAMPLE_RANDOM removal.)
I took a closer look at the arch/um code, and it wasn't as hard as I thought. I have a proposed set of patches to completely remove IRQF_SAMPLE_RANDOM that I will be sending out shortly....

I'll happily test them, please CC me.

BTW: On UML we have anyway CONFIG_UML_RANDOM to get good random numbers. It reads from thes host's /dev/random.

Thanks,
//richard