Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 13, 2007, [EMAIL PROTECTED] wrote: since the latest draft of the GPLv3 now discriminates against some uses (industrial vs commercial I think are the terms used) A User Product is either (1) a consumer product, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. does it even qualify as a Open Source lincense anymore by the OSI terms? The definition is about the hardware, not the software, so it may still qualify. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I815 suddenly unkown to agpgart?
oop, for 945GME like case, we should stop scan if still no detection. Updated patch here. [AGPGART] intel_agp: fix device probe Thanks, this also works on i815+ATI AGP. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, [EMAIL PROTECTED] wrote: If a company sells you hardware that includes a ROM that contains GPL'ed software, are they in violation of the GPL if they don't include a ROM burner in the hardware? Or are ROM burners like compilers, where you have to supply your own? this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix race condition about network device name allocation
On Wed, Jun 13, 2007 at 09:36:31AM -0700, Stephen Hemminger wrote: On Wed, 13 Jun 2007 12:45:21 +0300 Dan Aloni [EMAIL PROTECTED] wrote: On Mon, May 14, 2007 at 08:58:40AM -0700, Stephen Hemminger wrote: Kenji Kaneshige found this race between device removal and registration. On unregister it is possible for the old device to exist, because sysfs file is still open. A new device with 'eth%d' will select the same name, but sysfs kobject register will fial. The following changes the shutdown order slightly. It hold a removes the sysfs entries earlier (on unregister_netdevice), but holds a kobject reference. Then when todo runs the actual last put free happens. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] That patch breaks the bonding driver. After reverting it I avoid this crash: [..] I assume this happens when bonded slave device is removed? Yes, it's just a simple removal via sysfs. Which kernel version? 2.6.21.5 -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 13, 2007, Adrian Bunk [EMAIL PROTECTED] wrote: If the two courts are in the same country there's usually a higher court above both that can resolve this. But what if let's say the highest court in the USA and the highest court in Germany would disagree on such a matter? Upgrade the license so as to provide guidance as to the intent of the authors, such that the disagreement doesn't happen again. If there's room in each country's laws to fix the problem, that is. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mm: Fix memory/cpu hotplug section mismatch and oops.
(This is a resend of the earlier patch, this issue still needs to be
fixed.)
When building with memory hotplug enabled and cpu hotplug disabled, we
end up with the following section mismatch:
WARNING: mm/built-in.o(.text+0x4e58): Section mismatch: reference to
.init.text: (between 'free_area_init_node' and '__build_all_zonelists')
This happens as a result of:
- free_area_init_node()
- free_area_init_core()
- zone_pcp_init() -- all __meminit up to this point
- zone_batchsize() -- marked as __cpuinit fo
This happens because CONFIG_HOTPLUG_CPU=n sets __cpuinit to __init, but
CONFIG_MEMORY_HOTPLUG=y unsets __meminit.
Changing zone_batchsize() to __devinit fixes this.
__devinit is the only thing that is common between CONFIG_HOTPLUG_CPU=y and
CONFIG_MEMORY_HOTPLUG=y. In the long run, perhaps this should be moved to
another section identifier completely. Without this, memory hot-add
of offline nodes (via hotadd_new_pgdat()) will oops if CPU hotplug is
not also enabled.
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
--
mm/page_alloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index bd8e335..05ace44 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1968,7 +1968,7 @@ void zone_init_free_lists(struct pglist_data *pgdat,
struct zone *zone,
memmap_init_zone((size), (nid), (zone), (start_pfn), MEMMAP_EARLY)
#endif
-static int __cpuinit zone_batchsize(struct zone *zone)
+static int __devinit zone_batchsize(struct zone *zone)
{
int batch;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
regression tracking (Re: Linux 2.6.21)
* Newsgroups: gmane.linux.kernel * Date: Sun, 29 Apr 2007 10:50:22 -0700 (PDT) * From: Linus Torvalds On Sun, 29 Apr 2007, Andi Kleen wrote: Besides the primary point of bug tracking is not to be friendly to someone, but to (a) fix the bugs and (b) know how many bugs there for a given release. Any replacement would need to solve this problem too. Email does not solve it as far as I can see. Email fixes a _lot_ more bugs than bugzilla does. End of story. I don't think anybody who cannot accept that UNDENIABLE FACT should even participate in this discussion. Wake up and look at all the bugs we fix - most of them have never been in bugzilla. That's a FACT. Don't go around ignoring reality. I'm seeing this long (198) thread and just have no idea how it has ended (wiki? hand-mailing?). Just two general questions to Adrian. 1) You was maintainer of the woody backports, isn't it[0]? Why you didn't proposed (used) Debian's BTS as alternative to bugzilla, and how you did your regression tracking? What exactly doesn't fit? Full control by e-mail, comprehensive management, ML handling/redirection, tagging, sorting, searching? Finally, reportbug tool and web-inteface? 2) Your decision to stop activity, was that with debian because Sarge was release with known security hole in the kernel[1]? I'm just wonder. [0] google: woody backports Adrian Bunk [1] Message-ID: [EMAIL PROTECTED] Xref: news.gmane.org gmane.linux.debian.devel.kernel:27730 [Just take your news readers and have fun with Gmane!] [For those, who don't know what it is -- web :] Archived-At: http://permalink.gmane.org/gmane.linux.debian.devel.kernel/27730 --*-- Unfortunately this message is from a man, who was punished in very unfair manner by fellow developers. I'm not trying to rise this issue (sorry, if i'm trolling), just want to say, that life can be very unfair, when some wrong people are in power... Message-ID: [EMAIL PROTECTED] Xref: news.gmane.org gmane.linux.debian.devel.project:12330 Archived-At: http://permalink.gmane.org/gmane.linux.debian.devel.project/12330 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 02:55:52 Alexandre Oliva wrote: On Jun 13, 2007, Bongani Hlope [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote: if you distribute copies of such a program, [...] you must give the recipients all the rights that you have So, TiVo includes a copy of Linux in its DVR. And they give you the same right that they had, which is obtain free software that you can modify and redistribute. There's nothing in there that says they should give you the tools they used after they received the software, which is what you seem to be looking for. Can they modify the software in their device? Do they pass this right on? TiVo retains the right to modify that copy of Linux as it sees fit. It doesn't give the recipients the same right. It does, can't you modify their kernel source? It's not the kernel source. That's not where the TiVo anti-tampering machinery blocks modifications. It's about that copy of the kernel that ships in the device in object code. That's the one that TiVo customers ought to be entitled to modify, if TiVo can modify it itself. Where does it say you should be able to run you modifications on the same hardware? Where it says that you should pass on all the rights that you have. While TiVo retains the ability to replace, upgrade, fix, break or make any other change in the GPLed software in the device, it ought to pass it on to its customers. So according to your logic, I can go to Sharp's website and download the GPL source code for their Zaurus. But I don't own a Sharp Zaurus; to keep with your interpretation of the spirit of GPL, they have to give me a Zaurus so that I can run my modifications on the same hardware? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cdrom_sysctl_info fix
Hi,
Fix the cdrom_sysctl_info possible buffer overwrite bug. Somd codingstyle fixes
are included as well.
diff based on 2.6.22-rc4
Signed-off-by: Dave Young [EMAIL PROTECTED]
---
drivers/cdrom/cdrom.c | 186 +-
1 files changed, 102 insertions(+), 84 deletions(-)
diff -upr linux/drivers/cdrom/cdrom.c linux.new/drivers/cdrom/cdrom.c
--- linux/drivers/cdrom/cdrom.c 2007-06-14 14:05:04.0 +
+++ linux.new/drivers/cdrom/cdrom.c 2007-06-14 14:11:58.0 +
@@ -3290,102 +3290,120 @@ static struct cdrom_sysctl_settings {
} cdrom_sysctl_settings;
static int cdrom_sysctl_info(ctl_table *ctl, int write, struct file * filp,
- void __user *buffer, size_t *lenp, loff_t *ppos)
+ void __user *buffer, size_t *lenp, loff_t *ppos)
{
-int pos;
+ int pos;
struct cdrom_device_info *cdi;
char *info = cdrom_sysctl_settings.info;
+ int size = sizeof(cdrom_sysctl_settings.info);
if (!*lenp || (*ppos !write)) {
*lenp = 0;
return 0;
}
- pos = sprintf(info, CD-ROM information, VERSION \n);
+ pos = scnprintf(info, size, CD-ROM information, VERSION \n);
- pos += sprintf(info+pos, \ndrive name:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%s, cdi-name);
-
- pos += sprintf(info+pos, \ndrive speed:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, cdi-speed);
-
- pos += sprintf(info+pos, \ndrive # of slots:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, cdi-capacity);
-
- pos += sprintf(info+pos, \nCan close tray:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_CLOSE_TRAY) != 0);
-
- pos += sprintf(info+pos, \nCan open tray:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_OPEN_TRAY) != 0);
-
- pos += sprintf(info+pos, \nCan lock tray:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_LOCK) != 0);
-
- pos += sprintf(info+pos, \nCan change speed:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_SELECT_SPEED) != 0);
-
- pos += sprintf(info+pos, \nCan select disk:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_SELECT_DISC) != 0);
-
- pos += sprintf(info+pos, \nCan read multisession:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_MULTI_SESSION) != 0);
-
- pos += sprintf(info+pos, \nCan read MCN:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_MCN) != 0);
-
- pos += sprintf(info+pos, \nReports media changed:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_MEDIA_CHANGED) != 0);
-
- pos += sprintf(info+pos, \nCan play audio:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_PLAY_AUDIO) != 0);
-
- pos += sprintf(info+pos, \nCan write CD-R:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_CD_R) != 0);
-
- pos += sprintf(info+pos, \nCan write CD-RW:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_CD_RW) != 0);
-
- pos += sprintf(info+pos, \nCan read DVD:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_DVD) != 0);
-
- pos += sprintf(info+pos, \nCan write DVD-R:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_DVD_R) != 0);
-
- pos += sprintf(info+pos, \nCan write DVD-RAM:);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_DVD_RAM) != 0);
-
- pos += sprintf(info+pos, \nCan read MRW:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_MRW) != 0);
-
- pos += sprintf(info+pos, \nCan write MRW:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_MRW_W) != 0);
-
- pos += sprintf(info+pos, \nCan write RAM:\t);
- for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-next)
- pos += sprintf(info+pos, \t%d, CDROM_CAN(CDC_RAM) != 0);
+ pos += scnprintf(info + pos, size - pos, \ndrive name:\t);
+ for (cdi = topCdromPtr; cdi != NULL; cdi = cdi-next)
+ pos +=
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On 6/13/07, Luck, Tony [EMAIL PROTECTED] wrote: Above 5Mbytes, I started seeing problems. The line/word/char counts from wc started being 0 0 0. Not sure if this is a problem in wc dealing with a single line 5MBytes, or some other problem (possibly I was exceeding the per-process stack limit which is only 8MB on that machine). Interesting. If you're exceeding your stack ulimit, you should be seeing either an argument list too long message or getting a SIGSEGV. Have you tried bypassing wc and piping the output straight to a file? Ollie - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c-gpio: Add support for new-style clients
Hi Atsushi, On Wed, 13 Jun 2007 00:43:16 +0900 (JST), Atsushi Nemoto wrote: Use i2c_bit_add_numbered_bus() if device id specified, so that the i2c-gpio adapter works well with new-style pre-declared devices. Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED] --- diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c index a7dd546..8a62c26 100644 --- a/drivers/i2c/busses/i2c-gpio.c +++ b/drivers/i2c/busses/i2c-gpio.c @@ -142,7 +142,10 @@ static int __init i2c_gpio_probe(struct platform_device *pdev) adap-algo_data = bit_data; adap-dev.parent = pdev-dev; - ret = i2c_bit_add_bus(adap); + if (pdev-id == -1) + ret = i2c_bit_add_bus(adap); + else + ret = i2c_bit_add_numbered_bus(adap); if (ret) goto err_add_bus; This isn't sufficient. Before you call i2c_bit_add_numbered_bus(adap), you are supposed to set adap-nr to the desired i2c adapter number. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 13, 2007, Linus Torvalds [EMAIL PROTECTED] wrote: On Wed, 13 Jun 2007, Alexandre Oliva wrote: So, TiVo includes a copy of Linux in its DVR. Stop right there. You seem to make the mistake to think that software is something physical. Err, no. Software, per legal definitions in Brazil, US and elsewhere, require some physical support. That's the hard disk in the TiVO DVR, in this case. I don't see how this matters, though. TiVo retains the right to modify that copy of Linux as it sees fit. (b) They never modified a copy of Linux - they simply replaced it with another copy of Linux. The only thing that actually got *modified* was their hardware! Per this reasoning, nobody never modifies software. When you open a source file in your editor, you make changes to it, then save it, you're not modifying it, you're replacing it with another copy, and the only thing that actually got modified was the hardware. Maybe look what modify means in legal context? Then refer to the GPL: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, And their hardware (and firmware) will run some integrity checks on *whatever* copies of software they have. This is all totally outside Linux itself. Agreed. But as it turns out they use these checks to stop people from modifying the copy of Linux they ship in the device, and this restriction is a GPL violation because they don't provide information you need to build a functioning modified version. Btw, according to your _insane_ notion of a copy of software, you can never distribute GPL'd software on a CD-ROM, since you've taken away the right of people to modify that CD-ROM by burning and fixating it. You don't retain that right yourself. When you pass that copy on, you pass it on with all the rights that you have. No problem here. This is no different from the software on ROM. And I'm saying that the GPLv2 can mroe straightforwardly be read the way I read it - to talk about software, and to realize that software is not a copy, it's a more abstract thing. If you choose to disregard the legal meaning of the legal terms used in the GPLv2, you may have a point. that means that they have to give you access to and control over the SOFTWARE. Yes. That's all I'm saying. You just can't use the hardware to take that control away. That would be a violation of the license. Face it: the GPLv3 is a _new_ license. Making funamentally _different_ and _new_ restrictions that do not exist in the GPLv2, This is true. and do not exist in the preamble. This is not true. The spirit remains the same: let people modify and share the software. If the binary you got can't be created out of the corresponding sources, something is missing. If it won't run without this missing bit, you're missing functional portions of the source code. This all means the hardware is being used to impose a restriction on modification of the software, which is against the spirit of the GPL, and quite likely against its letter as well. If you don't want it to be so, you can always add an additional permission that clarifies this bit, such that TiVO and you will be happy. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] readahead: sanify file_ra_state names
Rename some file_ra_state variables and remove some accessors.
It results in much simpler code.
Kudos to Rusty!
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
include/linux/fs.h | 61 +++---
mm/readahead.c | 68 +++
2 files changed, 31 insertions(+), 98 deletions(-)
--- linux-2.6.22-rc4-mm2.orig/include/linux/fs.h
+++ linux-2.6.22-rc4-mm2/include/linux/fs.h
@@ -768,16 +768,12 @@ struct fown_struct {
/*
* Track a single file's readahead state
- *
- * #|==#==|
- * ^^ ^ ^
- * file_ra_state.la_index.ra_index .lookahead_index .readahead_index
*/
struct file_ra_state {
- pgoff_t la_index; /* enqueue time */
- pgoff_t ra_index; /* begin offset */
- pgoff_t lookahead_index;/* time to do next readahead */
- pgoff_t readahead_index;/* end offset */
+ pgoff_t start; /* where readahead started */
+ unsigned long size; /* # of readahead pages */
+ unsigned long async_size; /* do asynchronous readahead when
+ there are only # of pages ahead */
unsigned long ra_pages; /* Maximum readahead window */
unsigned long mmap_hit; /* Cache hit stat for mmap accesses */
@@ -787,59 +783,14 @@ struct file_ra_state {
};
/*
- * Measuring read-ahead sizes.
- *
- * |--- readahead size |
- * ===#|==#=|
- * |--- invoke interval --|-- lookahead size --|
- */
-static inline unsigned long ra_readahead_size(struct file_ra_state *ra)
-{
- return ra-readahead_index - ra-ra_index;
-}
-
-static inline unsigned long ra_lookahead_size(struct file_ra_state *ra)
-{
- return ra-readahead_index - ra-lookahead_index;
-}
-
-static inline unsigned long ra_invoke_interval(struct file_ra_state *ra)
-{
- return ra-lookahead_index - ra-la_index;
-}
-
-/*
* Check if @index falls in the readahead windows.
*/
static inline int ra_has_index(struct file_ra_state *ra, pgoff_t index)
{
- return (index = ra-la_index
- index ra-readahead_index);
-}
-
-/*
- * Where is the old read-ahead and look-ahead?
- */
-static inline void ra_set_index(struct file_ra_state *ra,
- pgoff_t la_index, pgoff_t ra_index)
-{
- ra-la_index = la_index;
- ra-ra_index = ra_index;
+ return (index = ra-start
+ index ra-start + ra-size);
}
-/*
- * Where is the new read-ahead and look-ahead?
- */
-static inline void ra_set_size(struct file_ra_state *ra,
- unsigned long ra_size, unsigned long la_size)
-{
- ra-readahead_index = ra-ra_index + ra_size;
- ra-lookahead_index = ra-ra_index + ra_size - la_size;
-}
-
-unsigned long ra_submit(struct file_ra_state *ra,
- struct address_space *mapping, struct file *filp);
-
struct file {
/*
* fu_list becomes invalid after file_free is called and queued via
--- linux-2.6.22-rc4-mm2.orig/mm/readahead.c
+++ linux-2.6.22-rc4-mm2/mm/readahead.c
@@ -245,21 +245,16 @@ unsigned long max_sane_readahead(unsigne
/*
* Submit IO for the read-ahead request in file_ra_state.
*/
-unsigned long ra_submit(struct file_ra_state *ra,
+static unsigned long ra_submit(struct file_ra_state *ra,
struct address_space *mapping, struct file *filp)
{
- unsigned long ra_size;
- unsigned long la_size;
int actual;
- ra_size = ra_readahead_size(ra);
- la_size = ra_lookahead_size(ra);
actual = __do_page_cache_readahead(mapping, filp,
- ra-ra_index, ra_size, la_size);
+ ra-start, ra-size, ra-async_size);
return actual;
}
-EXPORT_SYMBOL_GPL(ra_submit);
/*
* Set the initial window size, round to next power of 2 and square
@@ -288,7 +283,7 @@ static unsigned long get_init_ra_size(un
static unsigned long get_next_ra_size(struct file_ra_state *ra,
unsigned long max)
{
- unsigned long cur = ra-readahead_index - ra-ra_index;
+ unsigned long cur = ra-size;
unsigned long newsize;
if (cur max / 16)
@@ -305,28 +300,21 @@ static unsigned long get_next_ra_size(st
* The fields in struct file_ra_state represent the most-recently-executed
* readahead attempt:
*
- *| last readahead window |
- * |-- application walking here --|
- * ==#|==#=|
- * ^la_index^ra_index ^lookahead_index ^readahead_index
- *
- * [ra_index, readahead_index)
[PATCH 1/2] readahead: split ondemand readahead interface into two functions
Split ondemand readahead interface into two functions. I think this
makes it a little clearer for non-readahead experts (like Rusty).
Internally they both call ondemand_readahead(), but the page argument
is changed to an obvious boolean flag.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/ext3/dir.c |4 -
fs/ext4/dir.c |4 -
fs/splice.c|6 +-
include/linux/mm.h | 20 ++---
mm/filemap.c | 10 ++--
mm/readahead.c | 95 ++-
6 files changed, 84 insertions(+), 55 deletions(-)
--- linux-2.6.22-rc4-mm2.orig/fs/ext3/dir.c
+++ linux-2.6.22-rc4-mm2/fs/ext3/dir.c
@@ -139,10 +139,10 @@ static int ext3_readdir(struct file * fi
pgoff_t index = map_bh.b_blocknr
(PAGE_CACHE_SHIFT - inode-i_blkbits);
if (!ra_has_index(filp-f_ra, index))
- page_cache_readahead_ondemand(
+ page_cache_sync_readahead(
sb-s_bdev-bd_inode-i_mapping,
filp-f_ra, filp,
- NULL, index, 1);
+ index, 1);
filp-f_ra.prev_index = index;
bh = ext3_bread(NULL, inode, blk, 0, err);
}
--- linux-2.6.22-rc4-mm2.orig/fs/ext4/dir.c
+++ linux-2.6.22-rc4-mm2/fs/ext4/dir.c
@@ -138,10 +138,10 @@ static int ext4_readdir(struct file * fi
pgoff_t index = map_bh.b_blocknr
(PAGE_CACHE_SHIFT - inode-i_blkbits);
if (!ra_has_index(filp-f_ra, index))
- page_cache_readahead_ondemand(
+ page_cache_sync_readahead(
sb-s_bdev-bd_inode-i_mapping,
filp-f_ra, filp,
- NULL, index, 1);
+ index, 1);
filp-f_ra.prev_index = index;
bh = ext4_bread(NULL, inode, blk, 0, err);
}
--- linux-2.6.22-rc4-mm2.orig/fs/splice.c
+++ linux-2.6.22-rc4-mm2/fs/splice.c
@@ -304,8 +304,8 @@ __generic_file_splice_read(struct file *
* readahead/allocate the rest.
*/
if (spd.nr_pages nr_pages)
- page_cache_readahead_ondemand(mapping, in-f_ra, in,
- NULL, index, req_pages - spd.nr_pages);
+ page_cache_sync_readahead(mapping, in-f_ra, in,
+ index, req_pages - spd.nr_pages);
while (spd.nr_pages nr_pages) {
/*
@@ -360,7 +360,7 @@ __generic_file_splice_read(struct file *
page = pages[page_nr];
if (PageReadahead(page))
- page_cache_readahead_ondemand(mapping, in-f_ra, in,
+ page_cache_async_readahead(mapping, in-f_ra, in,
page, index, req_pages - page_nr);
/*
--- linux-2.6.22-rc4-mm2.orig/include/linux/mm.h
+++ linux-2.6.22-rc4-mm2/include/linux/mm.h
@@ -1146,12 +1146,20 @@ int do_page_cache_readahead(struct addre
pgoff_t offset, unsigned long nr_to_read);
int force_page_cache_readahead(struct address_space *mapping, struct file
*filp,
pgoff_t offset, unsigned long nr_to_read);
-unsigned long page_cache_readahead_ondemand(struct address_space *mapping,
- struct file_ra_state *ra,
- struct file *filp,
- struct page *page,
- pgoff_t offset,
- unsigned long size);
+
+void page_cache_sync_readahead(struct address_space *mapping,
+ struct file_ra_state *ra,
+ struct file *filp,
+ pgoff_t offset,
+ unsigned long size);
+
+void page_cache_async_readahead(struct address_space *mapping,
+ struct file_ra_state *ra,
+ struct file *filp,
+ struct page *pg,
+ pgoff_t offset,
+ unsigned long size);
+
unsigned long max_sane_readahead(unsigned long nr);
/* Do stack extension */
--- linux-2.6.22-rc4-mm2.orig/mm/filemap.c
+++ linux-2.6.22-rc4-mm2/mm/filemap.c
@@ -913,15 +913,15 @@ void do_generic_mapping_read(struct addr
find_page:
page = find_get_page(mapping, index);
if (!page) {
- page_cache_readahead_ondemand(mapping,
- ra, filp, page,
+
[PATCH 0/2] ondemand readahead simplifications
Andrew, With the help from Rusty, the interface and data structure of ondemand readahead are made more clear: readahead: split ondemand readahead interface into two functions readahead: sanify file_ra_state names diffstat: fs/ext3/dir.c |4 - fs/ext4/dir.c |4 - fs/splice.c|6 - include/linux/fs.h | 61 +-- include/linux/mm.h | 20 +++-- mm/filemap.c | 10 +- mm/readahead.c | 165 +-- 7 files changed, 116 insertions(+), 154 deletions(-) Regards, Fengguang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c-gpio: Make some internal functions static
On Wed, 13 Jun 2007 13:16:41 +0200, Haavard Skinnemoen wrote: On Wed, 13 Jun 2007 00:54:38 +0900 (JST) Atsushi Nemoto [EMAIL PROTECTED] wrote: i2c_gpio_getsda() and i2c_gpio_getscl() are only used in this file. Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED] Ah, of course. Hopefully this is the last remaining sign that the driver started out as a quick hack :-) Acked-by: Haavard Skinnemoen [EMAIL PROTECTED] Correct. Applied, thanks. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 01:51:13 Alexandre Oliva wrote: On Jun 14, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: I've never had a reason to want to change the way any device like a TiVO works. So I can't comment on this. Have you never wanted to improve any aspect of the software in your cell phone? In your TV, VCR, DVD player, anything? In the microwave oven, maybe? Nope. I've been tempted several times, but decided that the extra bits I'd thought about wouldn't add anything to the device. On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote: In 95% of the desktop computers, you can't make changes to the OS that runs on it. Whom is this good for? Faulty logic. I have yet to find a computer that I couldn't change the OS on. I was not talking about installing another OS, I was talking about making changes to the OS. As in, improving one particular driver, avoiding a blue screen, stuff like that. Ah, well... In the case of Windos and other proprietary OS's I try to educate people and get them to switch. I don't, personally, have any computers that run Windows (and I switched my Palm back to PalmOS because it wasn't getting the same performance under Linux - which rather surprised me. And rather than fight with it I just switched it back. Or do you mean transferring the recorded copies off the TiVO and on to a different medium? Sure. Such that I can watch shows while wasting time in public transportation, in an airplane, whatever. Under the US Copyright law I'm not sure that making a second copy like that is legal. IIRC, Fair Use only allows for one copy. DRM, I do agree, gets in the way of Fair Use. And the fact that TiVO can be, and has been modified remotely to add restrictions on what users could do, means nothing you do with it is safe. You, and everything you've recorded with the TiVO, are at the mercy of this one company. As has been noted in their TOS and the licenses for the hardware from the start. The FSF itself explicitly reserves the right to change the GPL at any time - which is no different. (when you remove all the bits explaining the purpose of the license) So you're not concerned that you're potentially pushing companies that would otherwise be major consumers of GPL'd software away? That doesn't make sense to me. What would their consuming GPL software buy us, if they won't respect users' freedoms, which is the very reason behind the GPL? I'm not referring to companies that are embedding GPL'd software in their products. The companies I'm referring to are the ones that would like to use GPL'd software internally. A lot of them would probably have private modifications that would never be distributed - and under the GPLv2 it is clear that you can keep modifications private as long as you don't distribute them. Pushing them away means that they'd not do that because they would be concerned that the license will change under them in such a way that even those private modifications need to be released to the public. (and don't try to argue that even though those modifications are truly private (to the company) they should be released anyway to comply with the spirit of the license. It is made clear that it isn't by the text of the license itself) Heck, if they don't want to play by the rules, that's up to them. But then they shouldn't use the software at all. Yeah, I wish they'd rather play by the rules, but if they don't want to, too bad, for us and for them. Why should I repeat Linus' explanation of the ways that GPLv3 violates the spirit of GPLv2? Don't worry about parrotting here, he hasn't provided that explanation yet ;-) Please give it a try. But he has. Whether you have accepted that his explanations are valid or not doesn't change the fact. BTW, what license is Linux licensed under? It's GPLv2 plus userland exception, right? (There's some additional module exception, right?) The kernel itself is GPLv2 (only). Individual components - even individual files - have other licenses or retain the any later version clause. (Someone pointed out, earlier in this thread, that there is GPLv1.1 code in the kernel) And why shouldn't I pose it as a matter of Personal Taste? The biggest and most powerful voice in the FSF says I don't like Tivoization and I don't like DRM and when the GPLv3 appears it has language that makes those violations of the license. Have you ever wondered *why* he doesn't like them? Not really. I've always figured he had reasons similar to mine for not liking DRM. As to his dislike of Tivoization, well, that I've always attributed to the fact that someone at that company managed to outsmart him. (and no, I wasn't being serious with that last line) Could it possibly be because they harm the goal of his life, which is to enable people to live their digital lives in freedom? Just like people have started using GNU/Linux or GNU+Linux to refer
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 14 Jun 2007, Adrian Bunk wrote: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The question is whether this includes private keys. No. That's the question as the FSF would like to frame it. No. The FSF actually does *not* want to take this position. That's why it chose the formulation of Installation Instructions. It doesn't share my view that the keys needed to sign a binary in order for it to work are part of the source code. And you could actually replace their copy of Linux with another one. It would have to have the same SHA1 to actually start _running_, but that's the hardware's choice. That's the hardware imposing a restriction on modification of the software. It doesn't matter how elaborate the excuse is to justify denying users' freedoms: it's against the spirit of the GPL, and the GPL will be amended as needed to plug such holes. So take another example: I obviously distribute code that is copyrighted by others under the GPLv2. Do I follow the GPLv2? I sure as hell do! But do I give you the same rights as I have to modify the copy on master.kernel.org as I have? I sure as hell DO NOT! That's an interesting argument. People don't get your copy, so they're not entitled to anything about it. When they download the software, they get another copy, and they have a right to modify that copy. And here's a big clue for people: anybody who thinks that I'm violating the GPLv2 by not giving out my private SSH key to master.kernel.org is a f*cking moron! Agreed, except I'd probably use a lighter term. See any parallels here? Any parallel to a CD-ROM distribution, or a Tivo distribution? Yes. You see how TiVO is different? It is modifyable, and I actually receive the copy that TiVO can still modify, but I can't. The rights that the GPLv2 gives to the software, is to something much bigger than the particular copy of the software. Indeed, it's something bigger. But this doesn't exclude the smaller things, does it? Can people really not see the difference between the software and a particular encoded copy of the software? There is a difference. But the GPL doesn't limit itself to the former. It explicitly talks about copies. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cdrom_sysctl_info fix
Hi Andrew, Sorry for reply to myself, does the Jens Axboe's email is outdated? which one is the latest? And Jens, could you please update your email address? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 01:39:13 Michael Gerdau wrote: In Germany, not America. I should have qualified my statement to make it clear I mean In America. Sorry about the confusion. You shouldn't say America when you mean the US. Sorry, I slipped. I'm still trying to rid myself of the uniquely US belief that America == USA. Thanks for the reminder. DRH Best wishes, Michael -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c-gpio: Add support for new-style clients
On Thu, 14 Jun 2007 08:24:17 +0200, Jean Delvare [EMAIL PROTECTED] wrote:
+ if (pdev-id == -1)
+ ret = i2c_bit_add_bus(adap);
+ else
+ ret = i2c_bit_add_numbered_bus(adap);
if (ret)
goto err_add_bus;
This isn't sufficient. Before you call i2c_bit_add_numbered_bus(adap),
you are supposed to set adap-nr to the desired i2c adapter number.
Oh, indeed. That worked for me just I only used bus number 0.
Here is a revised patch.
Subject: [PATCH] i2c-gpio: Add support for new-style clients (take 2)
Use i2c_bit_add_numbered_bus() if platform_device id specified, so
that the i2c-gpio adapter works well with new-style pre-declared
devices.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index a7dd546..88c5735 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -142,7 +142,12 @@ static int __init i2c_gpio_probe(struct platform_device
*pdev)
adap-algo_data = bit_data;
adap-dev.parent = pdev-dev;
- ret = i2c_bit_add_bus(adap);
+ if (pdev-id == -1)
+ ret = i2c_bit_add_bus(adap);
+ else {
+ adap-nr = pdev-id;
+ ret = i2c_bit_add_numbered_bus(adap);
+ }
if (ret)
goto err_add_bus;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, Dmitry Torokhov [EMAIL PROTECTED] wrote: On Wednesday 13 June 2007 21:59, Alexandre Oliva wrote: For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. So if I am a sole author of a program and I chose to distribute it under GPL then you're not a licensee, you're a licensor, and these terms don't apply to you. Already covered upthread BTW. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] hwbkpt: Hardware breakpoints (was Kwatch)
I really don't understand your point here. What's wrong with bp_show?
Is it all the preprocessor conditionals? I thought that was how we had
agreed portable code should determine which types and lengths were
supported on a particular architecture.
That part is fine. The problem is fetching the hw_breakpoint.len field
directly and expecting it to contain the API values. In an implementation
done as I've been referring to, there is no need for any field to contain
the HW_BREAKPOINT_LEN_8 value, and it's a waste to store one. If it were
hw_breakpoint_get_len(bp), that would be fine.
Consider that the definition of struct hw_breakpoint is in
include/asm-generic/. [...]
The one thing which makes sense to me is that some architectures might
want to store type and/or length bits in along with the address field.
Indeed, that is the natural thing (and all the bits needed) on several.
I hadn't raised this before since I was having so much trouble already
convincing you about storing things in machine-dependent fashion so that
users cannot just use the struct fields directly.
I really think it would be cleanest all around to use just:
struct arch_hw_breakpoint info;
in place of address union, len, type in struct hw_breakpoint. Then each
arch provides hw_breakpoint_get_{kaddr,uaddr,len,type} inlines. For
storing, each arch can define hw_breakpoint_init(addr, len, type) (or
maybe k/u variants). This can be used by callers directly if you want to
keep register_hw_breakpoint to one argument, or could just be internal if
register_hw_breakpoint takes the three more args. If callers use it
directly, there can also be an INIT_ARCH_HW_BREAKPOINT(addr, len, type)
for use in struct hw_breakpoint_init initializers.
On x86 use:
struct arch_hw_breakpoint_info {
union {
const void *kernel;
const void __user *user;
unsigned long va;
} address;
u8 len;
u8 type;
} __attribute__((packed));
and the size of struct hw_breakpoint won't increase.
What about DR_STEP? i.e., if DR_STEP was set from a single-step and then
there was a DR_TRAPn debug exception, is DR_STEP still set? If DR_TRAPn
was set and then you single-step, is DR_TRAPn cleared?
I didn't experiment with using DR_STEP. There wasn't any simple way to
cause a single-step exception. Perhaps if I were more familiar with
kprobes...
It's easy for user mode with gdb. kprobes is simple to use, and it
always does a single-step to execute (a copy of) the instruction that
was overwritten with the breakpoint. So, write a module that does:
int testvar=0;
asm(.globl testme; testme: movl $17,testvar; ret);
void testme();
testinit() {
... register kprobe at testme ...
... register hw_breakpoint at testvar ...
testme()
}
Your kprobe handlers don't have to actually do anything at all, if you
are just hacking the low-level code so see what %dr6 values you get at
each trap.
I decided on something simpler than messing around with Kconfig.
I still think it's the proper thing to make it conditional, not always
built in. But it's a pedantic point.
This is getting pretty close to a final form. The patch below is for
2.6.22-rc3. See what you think...
Indeed I think we have come nearly as far as we will before we have a few
arch ports get done and some heavy use to find the rough edges. Thanks
very much for being so accomodating to all my criticism, which I hope has
been constructive.
+inline const void *hw_breakpoint_get_kaddr(struct hw_breakpoint *bp)
These need to be static inline. Here you're defining a global function
in every .o file that uses the header.
+ get_debugreg(dr6, 6);
+ set_debugreg(0, 6); /* DR6 may or may not be cleared by the CPU */
+ if (dr6 (DR_TRAP0|DR_TRAP1|DR_TRAP2|DR_TRAP3))
+ tsk-thread.vdr6 = 0;
Some comment here about this conditional clearing, please.
+
+/*
+ * HW breakpoint additions
+ */
+
+#define HB_NUM 4 /* Number of hardware breakpoints */
Need #ifdef __KERNEL__ around all these additions to debugreg.h.
+static inline void arch_update_thbi(struct thread_hw_breakpoint *thbi,
For local functions in a source file (not a header), it's standard form
now just to define them static, not static inline. For these trivial
ones, the compiler will always inline them.
Thanks,
Roland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, Bongani Hlope [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 02:55:52 Alexandre Oliva wrote: While TiVo retains the ability to replace, upgrade, fix, break or make any other change in the GPLed software in the device, it ought to pass it on to its customers. So according to your logic, I can go to Sharp's website and download the GPL source code for their Zaurus. But I don't own a Sharp Zaurus; to keep with your interpretation of the spirit of GPL, they have to give me a Zaurus so that I can run my modifications on the same hardware? Sharp can modify the copy of the code in your Zaurus as much as you do, when you don't have a Zaurus. I don't see how you can get to the conclusion that they have to give you a Zaurus, when all you're getting is software. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
On 6/13/07, Chris Mason [EMAIL PROTECTED] wrote: On Wed, Jun 13, 2007 at 12:14:40PM -0400, Albert Cahalan wrote: On 6/13/07, Chris Mason [EMAIL PROTECTED] wrote: On Wed, Jun 13, 2007 at 01:45:28AM -0400, Albert Cahalan wrote: * secure delete via destruction of per-file or per-block random crypto keys I'd rather keep secure delete as a userland problem (or a layered FS problem). When you take backups and other copies of the file into account, it's a bigger problem than btrfs wants to tackle right now. It can't be a userland problem if you allow disk blocks to move. Volume resizing, logging/journalling, etc. -- they combine to make the userland solution essentially impossible. (one could wipe the whole partition, or maybe fill ALL space on the volume) Right about here is where I would insert a long story about ecryptfs, or encryption solutions that happen all in userland. At any rate, it is outside the scope of v1.0, even though I definitely agree it is an important problem for some people. I'm sure you do have a nice long story, and I'm sure it seems correct, but there is something not quite right about the add-on hacks. BTW, I'm suggesting that this be about deletion, not protection of data you wish to keep. It covers more than just file bodies. It covers inode data, block allocations, etc. * atomic creation of copy-on-write directory trees Do you mean something more fine grained than the current snapshotting system? I believe so. Example: I have a linux-2.6 directory. It's not a mount point or anything special like that. I want to copy it to a new directory called wip, without actually copying all the blocks. To all the normal POSIX API stuff, this copy should look like the result of cp -a, not hard links. This would be a snapshot, which has to be done on a subvolume right now. It is not as nice as being able to pick a random directory, but I've only been able to get this far by limiting the feature scope significantly. What I did do was make subvolumes very cheap...just make a bunch of them. Can a regular user create and use a subvolume? If not, then this doesn't work. (if so, then I have other concerns...) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thu, Jun 14, 2007 at 01:58:26AM -0300, Alexandre Oliva wrote: On Jun 14, 2007, Bron Gondwana [EMAIL PROTECTED] wrote: Tivo gets sick of the endless flamewars on lkml, signs a copy of QNX, pushes it out to the hardware. No more Linux on Tivo. What do we lose? Do we actually get any benefit whatsoever from TiVO's choice of Linux as the kernel for its device? Sure, if they make any changes or fixes to Linux. Other than that, only the same benefit that Microsoft get from Windows piracy - TiVo employees become familiar with Linux and are more likely to use it and maybe contribute more in another job later. What we don't get is TiVo having a better kernel than everyone else because they've put some work into extending it without giving that work back. I see stuff in arch/powerpc/kernel/ which is Copyright TiVo, Inc and more recent stuff in usb/net/asix.c and usb/net/mcs7830.c which is more than I've ever contributed to the kernel, despite making extensive use and even selling services where I ran servers with Linux on them but didn't allow my customers to change the kernel on the servers if there was some feature they wanted to play with. Do TiVO customers lose anything from the change from one non-Free software to another? (the Linux binary, as shipped in the TiVO, has become non-Free) Not particularly, no. Other than maybe some nice features that TiVo gains from being able to use Linux. Bron. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT] fix migrating softirq [cause of network hang]
On Wednesday 13 June 2007 05:47:16 Steven Rostedt wrote: This patch temporarily binds the hardirq thread on the CPU that it runs the softirqs on. With this patch I have not seen my network hang. I ran it over night, doing compiles and such, and it seems fine. I would be able to cause the hang with various loads within a minute, now I can't cause it after several minutes. I'm assuming that this fix may fix other bugs too. I ran 2.6.21-rt10 + this patch with kernbench and then loops building a kernel (which would previously rapidly exhaust memory). It successfully built 400 kernels with make -j 32 on an 8 opteron machine with 8 GB of RAM and has so far completed 25 make -j on the same system. Looks like a winner to me so far. Thanks, -- Darren Hart IBM Linux Technology Center Realtime Linux Team - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
On Wed, Jun 13, 2007 at 10:11:12PM -0700, H. Peter Anvin wrote:
Oleg Verych wrote:
Thus, text mode on modern hardware isn't useable that much, only with
Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
But it's only option to unfortunately sucking X11, even with memory
bandwidth, you are talking about.
That's another reason to use the framebuffer console on laptops.
Last time i tried, it wasn't so much fun either. Mainly due to wild
cursor, that in normal text mode is well-behaved thing. Visually fb looks
much heavier. What's the benefit, if you see how windows in emacs are
painted? I don't know how giga-hertz/mem in cpu/sys-ram,
mega-hertz/ram in gpu are doing better job WRT to anything in visual
domain.
Also i don't know what to do in case of bugs/oops and officially closed
hardware specs on ATI chips{ref}.
About laptop. First and last time i ran new X11 (X.org) there, it drove
VGA fan really crazy. Don't know how it changed now, it was certainly due
to blindly switching 3D on. I don't want to remove *standard* drivers
because of that stupidness [see ref].
And after whole year being with Debian Sarge only, new application update
led me to just drop all that X stuff and run windoze (silently sold to me
with that laptop) if i need a stupid web browser with all that WEB 2.0
and Java crap...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Blackfin updates for 2.6.22-rc4
Hi Linus: Changes from last git-request-pull email: - remove some new platform and new driver patches out of this git-pull series as Paul mentioned - use scripts/checkpatch.pl to check and fix the coding style issues as Jeff pointed out please pull from: master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git master to receive the following updates: Aubrey Li (2): Blackfin arch: DMA code minor naming convention fix Blackfin arch: try to split up functions like this into smaller units according to LKML review Bryan Wu (2): Blackfin arch: fixup Blackfin MAINTIANERS team member list Blackfin SPI driver: fix bug SPI DMA incomplete transmission Jean-Christian de Rivaz (1): Blackfin SMC91X ethernet supporting driver: SMC91C111 LEDs are note drived in the kernel like in uboot Michael Hennerich (3): Blackfin arch: As Mike pointed out range goes form m..MAX_BLACKFIN_GPIO -1 Blackfin arch: add missing gpio.h header to fix compiling in some pm configurations Blackfin arch: fix bug can not wakeup from sleep via push buttons Mike Frysinger (19): Blackfin arch: remove defconfig file Blackfin arch: mark our memory init functions with __init so they get freed after init Blackfin arch: implement a basic /proc/sram file for L1 allocation visibility Blackfin arch: scrub old console defines Blackfin arch: update defconfigs Blackfin arch: unify differences between our diff head.S files -- no functional changes Blackfin arch: move more of our startup code to .init so it can be freed once we are up and running Blackfin arch: add proper ENDPROC() Blackfin arch: fix spelling typo in output Blackfin arch: add support for Alon Bar-Lev's dynamic kernel command-line Blackfin arch: make sure we initialize our L1 Data B section properly based on the linked kernel Blackfin arch: redo our linker script a bit Blackfin arch: move HI/LO macros into blackfin.h and punt the rest of macros.h as it includes VDSP macros we never use Blackfin serial driver: hook up our UARTs STP bit with userspaces CMSPAR Blackfin serial driver: ignore framing and parity errors Blackfin serial driver: actually implement the break_ctl() function Blackfin serial driver: decouple PARODD and CMSPAR checking from PARENB Blackfin RTC drivers: update MAINTAINERS information Blackfin SPI driver: tweak spi cleanup function to match newer kernel changes Robin Getz (1): Blackfin arch: all symbols were offset by 4k, since we didn't have the __text label. Roy Huang (1): Blackfin arch: fix bug ad1836 fails to build properly for BF533-EZKIT Simon Arlott (1): Blackfin arch: spelling fixes MAINTAINERS | 78 +- arch/blackfin/Kconfig | 35 - arch/blackfin/configs/BF533-EZKIT_defconfig | 241 +++- arch/blackfin/configs/BF533-STAMP_defconfig | 92 +- arch/blackfin/configs/BF537-STAMP_defconfig | 98 +- arch/blackfin/configs/BF561-EZKIT_defconfig | 192 +++- arch/blackfin/configs/PNAV-10_defconfig | 119 ++- arch/blackfin/defconfig | 1327 - arch/blackfin/kernel/bfin_dma_5xx.c |6 +- arch/blackfin/kernel/bfin_gpio.c | 14 +- arch/blackfin/kernel/entry.S |5 + arch/blackfin/kernel/irqchip.c|2 +- arch/blackfin/kernel/setup.c | 248 ++-- arch/blackfin/kernel/traps.c |2 +- arch/blackfin/kernel/vmlinux.lds.S| 166 +-- arch/blackfin/lib/divsi3.S|3 + arch/blackfin/lib/ins.S |4 +- arch/blackfin/lib/memchr.S|2 +- arch/blackfin/lib/memcmp.S|2 +- arch/blackfin/lib/memcpy.S|2 + arch/blackfin/lib/memmove.S |2 +- arch/blackfin/lib/memset.S|2 +- arch/blackfin/lib/modsi3.S|2 + arch/blackfin/lib/outs.S |3 + arch/blackfin/lib/smulsi3_highpart.S |2 + arch/blackfin/lib/udivsi3.S |2 + arch/blackfin/lib/umodsi3.S |4 + arch/blackfin/lib/umulsi3_highpart.S |2 + arch/blackfin/mach-bf533/boards/cm_bf533.c|2 +- arch/blackfin/mach-bf533/boards/ezkit.c |2 +- arch/blackfin/mach-bf533/head.S | 30 +- arch/blackfin/mach-bf533/ints-priority.c |2 +- arch/blackfin/mach-bf537/boards/generic_board.c |2 +- arch/blackfin/mach-bf537/boards/pnav10.c |2 +- arch/blackfin/mach-bf537/boards/stamp.c |2 +- arch/blackfin/mach-bf537/head.S | 35
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 02:36:12 Alexandre Oliva wrote: On Jun 14, 2007, Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 14 Jun 2007, Adrian Bunk wrote: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The question is whether this includes private keys. No. That's the question as the FSF would like to frame it. No. The FSF actually does *not* want to take this position. That's why it chose the formulation of Installation Instructions. It doesn't share my view that the keys needed to sign a binary in order for it to work are part of the source code. And you could actually replace their copy of Linux with another one. It would have to have the same SHA1 to actually start _running_, but that's the hardware's choice. That's the hardware imposing a restriction on modification of the software. It doesn't matter how elaborate the excuse is to justify denying users' freedoms: it's against the spirit of the GPL, and the GPL will be amended as needed to plug such holes. And? There is *absolutely* *nothing* in any version of the GPL *prior* to 3 that says that hardware cannot impose restrictions. What the GPL *does* say is that you can't add additional restrictions to the license - (IMHO) a piece of hardware having a restriction isn't an additional restriction added to the license. As well, as Linus stated, there is nothing *anywhere* - AFAICT, not even in GPLv3 - that says that you have to be able to run the software in place or on the same hardware. If a hardware manufacturer - like TiVO - uses GPL'd code in their product - and complies with the terms of the license - they aren't required to allow you to run modified code on that hardware. Without it mentioned anywhere in the GPL *OR* the assorted writings of RMS (who founded the FSF and wrote the original GPL) that modified software must be able to run on the same hardware then it cannot be in the spirit of the license to allow this. So take another example: I obviously distribute code that is copyrighted by others under the GPLv2. Do I follow the GPLv2? I sure as hell do! But do I give you the same rights as I have to modify the copy on master.kernel.org as I have? I sure as hell DO NOT! That's an interesting argument. People don't get your copy, so they're not entitled to anything about it. When they download the software, they get another copy, and they have a right to modify that copy. But you get the TiVO corporations copy of the software? I smell a logical fallacy here, but can't remember the name for it. And here's a big clue for people: anybody who thinks that I'm violating the GPLv2 by not giving out my private SSH key to master.kernel.org is a f*cking moron! Agreed, except I'd probably use a lighter term. See any parallels here? Any parallel to a CD-ROM distribution, or a Tivo distribution? Yes. You see how TiVO is different? It is modifyable, and I actually receive the copy that TiVO can still modify, but I can't. I don't. You don't get the TiVO corporations copy of the software. You get your own copy, with all the rights that TiVO had when receiving the software. The right to install and run the kernel in the TiVO device is independent of the rights to copy, modify, distribute and run the software. (because the GPL never guarantees you the right to run the software on a particular piece of hardware.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] Documentation of kernel messages
[EMAIL PROTECTED] wrote: On Wed, 13 Jun 2007 12:04:56 PDT, Joe Perches said: I believe it better to simply add __FILE__ __LINE__ to the macro rather than some other externally specified unique identifier that adds developer overhead and easily gets stale. There's been plenty of times I've wished for that. Now if we just found a way to do something sane for drivers/net/wireless/mac80211/iwlwifi/base.c ;) Why don't you just redefine the KERN_* macros which is used by almost every printk in the system to contain said __FILE__ and __LINE__, then? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
man-pages-2.56 is released
Gidday, I just released man-pages-2.56. This release is now available for download at: http://www.kernel.org/pub/linux/docs/manpages or ftp://ftp.kernel.org/pub/linux/docs/manpages and soon at: ftp://ftp.win.tue.nl/pub/linux-local/manpages Changes that may be of interest to readers of this list are noted below. Cheers, Michael (man-pages maintainership is supported by Google, as a Google engineer 20% project.) -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages/ read the HOWTOHELP file and grep the source files for 'FIXME'. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 01:51:13 Alexandre Oliva wrote: On Jun 14, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote: In 95% of the desktop computers, you can't make changes to the OS that runs on it. Whom is this good for? Faulty logic. I have yet to find a computer that I couldn't change the OS on. I was not talking about installing another OS, I was talking about making changes to the OS. As in, improving one particular driver, avoiding a blue screen, stuff like that. Ah, well... In the case of Windos and other proprietary OS's I try to educate people and get them to switch. Good. So I presume you'd tell them to switch away from a turned-proprietary GNU/Linux operating system as well, right? So, again, what do we gain if companies abuse the GPL and disrespect users' rights that we meant them to respect? Or do you mean transferring the recorded copies off the TiVO and on to a different medium? Sure. Such that I can watch shows while wasting time in public transportation, in an airplane, whatever. Under the US Copyright law I'm not sure that making a second copy like that is legal. IIRC, Fair Use only allows for one copy. Even if you delete the first copy? Actually, I thought fair use in US entitled you to make a backup copy. So the copy in your TiVO would be your original, and the external copy would be your fair-use backup. As has been noted in their TOS and the licenses for the hardware from the start. If it is used to disrespect the inalienable freedoms associated with the GPL software in the device, it seems like a license violation to me. The FSF itself explicitly reserves the right to change the GPL at any time - which is no different. Actually, it's completely different. If the FSF revises the GPL, the old version remains available for anyone to use for any new software, and all software released under the old version remains available under that old version. In contrast, your TiVO may get a software upgrade without your permission that will take your rights away from that point on, and there's very little you can do about it, other than unplugging it from the network to avoid the upgrade if it's not too late already. A lot of them would probably have private modifications that would never be distributed - and under the GPLv2 it is clear that you can keep modifications private as long as you don't distribute them. Likewise with GPLv3. Pushing them away means that they'd not do that because they would be concerned that the license will change under them in such a way that even those private modifications need to be released to the public. This would not only change the spirit of the license, but turn it into a non-Free Software license. And then, again, the license can't possibly be changed from under them. A new revision of the GPL would only affect software licensed under that new revision. If you already got it under an earlier revision, you know what you got, and nobody can take that away from you. (and don't try to argue that even though those modifications are truly private (to the company) they should be released anyway to comply with the spirit of the license. It is made clear that it isn't by the text of the license itself) How could you possibly come to the conclusion that forcing anyone to release private modifications would be in compliance with the spirit of the license? can != must Why should I repeat Linus' explanation of the ways that GPLv3 violates the spirit of GPLv2? Don't worry about parrotting here, he hasn't provided that explanation yet ;-) Please give it a try. But he has. Whether you have accepted that his explanations are valid or not doesn't change the fact. His explanation is based on a reading of the license that doesn't match what its authors meant. I guess the authors know better what they meant the spirit of the license to be than someone else who studied it a lot but that until very recently couldn't even tell the spirit from the legal terms. Just like people have started using GNU/Linux or GNU+Linux to refer to Linux No, no, you got it wrong. Linux is the kernel. GNU was the nearly-complete operating system it fit in. GNU+Linux is a complete operating system. *AND* you cut out the bit where I said I have no problems with it Referring to Linux as GNU/Linux would be wrong, because Linux is the kernel, and that's unrelated with the GNU operating system. It's the combination of them that forms GNU+Linux. And it's referring to this combination as Linux that is wrong. I'm sorry that I got the impression that you meant the combination when you wrote refer to Linux above. It looked like you meant the combination, since I've never seen anyone call the kernel GNU/Linux or GNU+Linux. Never claimed otherwise. The problem is that using a composite name like
Re: [patch 01/03] kbuild, asm-values: infrastructure
Jun 13, 2007 at 01:36:51AM +0200, asm-values patch set: * header with widely used value definitions * handle all asm-related things in one file (Makefile.asm) * move some asm bits from Makefile.build there (rule %.s:%.c) * add script to generate headers from assembles output (hopefully better output, MIPS testing/joining to all arch probably needed) rfc-by: Oleg Verych --- So, is it another not so juicy lets-break-it-all stuff from me, or it just doesn't apply for you? I thought update all that asm-offsets stuff just like that. I want to know, why it does not fit. Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 0/9] TOMOYO Linux security module.
The following patches are TOMOYO Linux 2.0. TOMOYO Linux 2.0 is implemented as a LSM module. If you want to use older kernel, please download from http://osdn.dl.sourceforge.jp/tomoyo/25693/tomoyo-lsm-2.0-20070605.tar.gz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thu, Jun 14, 2007 at 02:51:13AM -0300, Alexandre Oliva wrote: On Jun 14, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: I've never had a reason to want to change the way any device like a TiVO works. So I can't comment on this. Have you never wanted to improve any aspect of the software in your cell phone? In your TV, VCR, DVD player, anything? In the microwave oven, maybe? This is perhaps the part that's the most interesting. For the very small number of people that _do_ want to change these things (usually at the expense of a voided warranty, in the consumer device case), there's always a way to make these changes, even if you must resort to hardware hacking. Trying to mandate this sort of functionality in the license might make it easier for a few people to get their code loaded, but the vast majority of users have zero interest in anything like this. I don't see how you can claim that the vendor is infringing on your freedom, _you_ made the decision to go out and buy the product knowing that the vendor wasn't going to go out of their way to help you hack the device. In many cases the vendor doesn't even have the option (802.11b channels and certification come to mind, GSM, etc.) of opening things up to the end user, and making changes to the license isn't going to magically change any of this. If you don't like what the vendor has done with the product, you have the freedom to not support the vendor, and to try and encourage people to follow suit. As an example, I simply opted not to buy a tivo since I wasn't able to do what I wanted with it out of the box, rather than opting to rant about it (or coin an idiotic buzzword) much to the dismay of every other person on a mailing list. This was neither something I lost a great deal of sleep over, nor did I at any time feel like my freedom was being eroded. True story. If the vendor's bottom line is measurably impacted, they may even reevaluate their position on supporting device hacking, but it's certainly not going to be through draconian licensing that vendors suddenly decide to play nice. There were certainly enough vendors that followed the letter of the GPLv2 without following the spirit of the license, with varied benefit (especially with consumer device vendors). Imposing additional constraints under the guise of the FSF's current version of freedom isn't going to get these sorts of vendors working any better with the community. You could of course argue that these vendors have nothing to offer the community, and so they shouldn't be tolerated at all, but that assumes that being able to load arbitrary code on their hardware and the usefulness of whatever contributions they have to make to the software are directly coupled some how. This has never been the case, and it only seems to be a mindset that has started circulating when the GPLv3 came about. One idly wonders who exactly the FSF feels they're speaking for at this point.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 7/9] Auditing interface.
This patch makes access logs sent to auditing subsystem.
Although TOMOYO Linux has /proc interface for access logs,
we were advised to use auditing subsystem (after we introduced
TOMOYO Linux 1.0 on December 2005, http://lkml.org/lkml/2005/12/21/63 )
and we did so in TOMOYO Linux 2.0.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/audit.c | 52
1 file changed, 52 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/audit.c
linux-2.6.21.5-tomoyo/security/tomoyo/audit.c
--- linux-2.6.21.5/security/tomoyo/audit.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/audit.c 2007-06-14
15:06:10.0 +0900
@@ -0,0 +1,52 @@
+/*
+ * security/tomoyo/audit.c
+ *
+ * Audit functions for TOMOYO Linux
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include tomoyo.h
+#include linux/audit.h
+
+/* move to include/linux/audit.h */
+#define AUDIT_TOMOYO 2001
+
+char *tomoyo_init_audit_log(int *len)
+{
+ char *buf;
+ struct timeval tv;
+ struct task_struct *task = current;
+ const char *domainname =
+ ((struct tomoyo_security *)
current-security)-domain_info-domainname-name;
+ do_gettimeofday(tv);
+ *len += strlen(domainname) + 256;
+ if ((buf = tomoyo_alloc(*len)) != NULL)
+ snprintf(buf,
+(*len) - 1,
+#timestamp=%lu pid=%d uid=%d gid=%d euid=%d egid=%d
+suid=%d sgid=%d fsuid=%d fsgid=%d\n%s\n,
+tv.tv_sec, task-pid, task-uid, task-gid, task-euid,
task-egid,
+task-suid, task-sgid, task-fsuid, task-fsgid,
domainname);
+ return buf;
+}
+
+/*
+ * Write audit log.
+ * Caller must allocate buf with tomoyo_init_audit_log().
+ */
+int tomoyo_write_audit_log(char *buf, const int is_granted)
+{
+ struct audit_buffer *ab;
+ ab = audit_log_start(current-audit_context, GFP_KERNEL, AUDIT_TOMOYO);
+ if (ab) {
+ audit_log_format(ab,
+%s\n%s,
+is_granted ? TOMOYO_GRANT_LOG :
TOMOYO_REJECT_LOG, buf);
+ audit_log_end(ab);
+ }
+ tomoyo_free(buf);
+ return ab ? 0 : -ENOMEM;
+}
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 8/9] File access control functions.
This is the main part for profiling and controlling file access.
We thought checking old pathname and new pathname separately
for rename() and link() operation is a too rough access control
and we are checking both pathnames using tomoyo_check_double_write_acl().
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/file.c | 1126
+
1 file changed, 1126 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/file.c
linux-2.6.21.5-tomoyo/security/tomoyo/file.c
--- linux-2.6.21.5/security/tomoyo/file.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/file.c2007-06-05
00:00:00.0 +0900
@@ -0,0 +1,1126 @@
+/*
+ * security/tomoyo/file.c
+ *
+ * File access control functions for TOMOYO Linux.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include tomoyo.h
+#include realpath.h
+#define ACC_MODE(x) (\000\004\002\006[(x)O_ACCMODE])
+
+/* VARIABLES */
+
+extern struct semaphore domain_acl_lock;
+
+/* The structure for globally readable files. */
+
+struct globally_readable_file_entry {
+ struct globally_readable_file_entry *next;
+ const struct path_info *filename;
+ int is_deleted;
+};
+
+/* The structure for filename patterns. */
+
+struct pattern_entry {
+ struct pattern_entry *next;
+ const struct path_info *pattern;
+ int is_deleted;
+};
+
+/* The structure for non-rewritable-by-default file patterns. */
+
+struct no_rewrite_entry {
+ struct no_rewrite_entry *next;
+ const struct path_info *pattern;
+ int is_deleted;
+};
+
+/* The structure for detailed write operations. */
+
+static struct {
+ const char *keyword;
+ const int paths;
+ int check_type;
+} acl_type_array[] = { /* mapping.txt */
+ { create, 1, 1 }, /* TOMOYO_TYPE_CREATE_ACL */
+ { unlink, 1, 1 }, /* TOMOYO_TYPE_UNLINK_ACL */
+ { mkdir,1, 1 }, /* TOMOYO_TYPE_MKDIR_ACL */
+ { rmdir,1, 1 }, /* TOMOYO_TYPE_RMDIR_ACL */
+ { mkfifo, 1, 1 }, /* TOMOYO_TYPE_MKFIFO_ACL */
+ { mksock, 1, 1 }, /* TOMOYO_TYPE_MKSOCK_ACL */
+ { mkblock, 1, 1 }, /* TOMOYO_TYPE_MKBLOCK_ACL */
+ { mkchar, 1, 1 }, /* TOMOYO_TYPE_MKCHAR_ACL */
+ { truncate, 1, 1 }, /* TOMOYO_TYPE_TRUNCATE_ACL */
+ { symlink, 1, 1 }, /* TOMOYO_TYPE_SYMLINK_ACL */
+ { link, 2, 1 }, /* TOMOYO_TYPE_LINK_ACL */
+ { rename, 2, 1 }, /* TOMOYO_TYPE_RENAME_ACL */
+ { rewrite, 1, 1 }, /* TOMOYO_TYPE_REWRITE_ACL */
+ { NULL, 0, 0 }
+};
+
+/* UTILITY FUNCTIONS */
+
+const char *tomoyo_acltype2keyword(const unsigned int acl_type)
+{
+ return (acl_type sizeof(acl_type_array) / sizeof(acl_type_array[0]))
+ ? acl_type_array[acl_type].keyword : NULL;
+}
+
+int tomoyo_acltype2paths(const unsigned int acl_type)
+{
+ return (acl_type sizeof(acl_type_array) / sizeof(acl_type_array[0]))
+ ? acl_type_array[acl_type].paths : 0;
+}
+
+static unsigned int tomoyo_check_acl_flags(const unsigned int index)
+{
+ if (index (sizeof(acl_type_array) / sizeof(acl_type_array[0])) - 1)
+ return acl_type_array[index].check_type;
+ printk(%s: Index %u is out of range. Fix the kernel source.\n,
__FUNCTION__, index);
+ return 0;
+}
+
+static int tomoyo_strendswith(const char *name, const char *tail)
+{
+ int len;
+ if (!name || !tail) return 0;
+ len = strlen(name) - strlen(tail);
+ return len = 0 strcmp(name + len, tail) == 0;
+}
+
+static struct path_info *tomoyo_get_path(struct dentry *dentry, struct
vfsmount *mnt)
+{
+ struct path_info_with_data { /* sizeof(struct path_info_with_data) =
PAGE_SIZE */
+ struct path_info head; /* Keep this first, this pointer is
passed to tomoyo_free(). */
+ char bariier1[16];
+ char body[TOMOYO_MAX_PATHNAME_LEN];
+ char barrier2[16];
+ } *buf = tomoyo_alloc(sizeof(*buf));
+ if (buf) {
+ int error;
+ if ((error = tomoyo_realpath_from_dentry2(dentry,
+ mnt,
+ buf-body,
+ sizeof(buf-body) -
1)) == 0) {
+ buf-head.name = buf-body;
+ tomoyo_fill_path_info(buf-head);
+ return buf-head;
+ }
+ tomoyo_free(buf);
+ buf = NULL;
+ printk(tomoyo_realpath_from_dentry = %d\n, error);
+ }
+ return NULL;
+}
+
+/* PROTOTYPES
[TOMOYO 9/9] Domain transition handler functions.
This is the main part for domain transition.
In TOMOYO Linux, domains are automatically created at runtime.
To make discussion smooth by reducing the amount of patches,
we pruned argv[0] checks (although we referred the need of argv[0] checking
at AppArmor's thread, http://lkml.org/lkml/2007/5/26/52 ).
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/domain.c | 782
+++
1 file changed, 782 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/domain.c
linux-2.6.21.5-tomoyo/security/tomoyo/domain.c
--- linux-2.6.21.5/security/tomoyo/domain.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/domain.c 2007-06-05
00:00:00.0 +0900
@@ -0,0 +1,782 @@
+/*
+ * security/tomoyo/domain.c
+ *
+ * Domain transition functions for TOMOYO Linux.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include tomoyo.h
+#include realpath.h
+#include linux/highmem.h
+#include linux/binfmts.h
+
+#ifndef for_each_process
+#define for_each_process for_each_task
+#endif
+
+/* VARIABLES */
+
+/* /sbin/init started? */
+extern int sbin_init_started;
+
+/* Lock for appending domain's ACL. */
+DECLARE_MUTEX(domain_acl_lock);
+
+/* The structure for program files to force domain reconstruction. */
+
+struct domain_initializer_entry {
+ struct domain_initializer_entry *next;
+ const struct path_info *domainname;/* This may be NULL */
+ const struct path_info *program;
+ u8 is_deleted;
+ u8 is_not;
+ u8 is_last_name;
+ u8 is_oldstyle;
+};
+
+/* The structure for domains to not to transit domains. */
+
+struct domain_keeper_entry {
+ struct domain_keeper_entry *next;
+ const struct path_info *domainname;
+ const struct path_info *program; /* This may be NULL */
+ u8 is_deleted;
+ u8 is_not;
+ u8 is_last_name;
+};
+
+/* The structure for program files that should be aggregated. */
+
+struct aggregator_entry {
+ struct aggregator_entry *next;
+ const struct path_info *original_name;
+ const struct path_info *aggregated_name;
+ int is_deleted;
+};
+
+/* The structure for program files that should be aliased. */
+
+struct alias_entry {
+ struct alias_entry *next;
+ const struct path_info *original_name;
+ const struct path_info *aliased_name;
+ int is_deleted;
+};
+
+/* VARIABLES */
+
+/* Domain creation lock. */
+static DECLARE_MUTEX(new_domain_assign_lock);
+
+/* UTILITY FUNCTIONS */
+
+int tomoyo_is_domain_def(const unsigned char *buffer)
+{
+ /* while (*buffer (*buffer = ' ' || *buffer = 127)) buffer++; */
+ return strncmp(buffer, TOMOYO_ROOT_NAME, TOMOYO_ROOT_NAME_LEN) == 0;
+}
+
+const char *tomoyo_get_last_name(const struct domain_info *domain)
+{
+ const char *cp0 = domain-domainname-name, *cp1;
+ if ((cp1 = strrchr(cp0, ' ')) != NULL) return cp1 + 1;
+ return cp0;
+}
+
+int tomoyo_read_self_domain(struct io_buffer *head)
+{
+ if (!head-read_eof) {
+ tomoyo_io_printf(head,
+%s,
+((struct tomoyo_security *)
current-security)-domain_info-domainname-name);
+ head-read_eof = 1;
+ }
+ return 0;
+}
+
+int tomoyo_add_domain_acl(struct acl_info *ptr, struct domain_info *domain,
struct acl_info *new_ptr)
+{
+ mb(); /* Instead of using spinlock. */
+ if (!ptr) domain-first_acl_ptr = (struct acl_info *) new_ptr;
+ else ptr-next = (struct acl_info *) new_ptr;
+ tomoyo_update_counter(TOMOYO_UPDATES_COUNTER_DOMAIN_POLICY);
+ return 0;
+}
+
+int tomoyo_del_domain_acl(struct acl_info *ptr)
+{
+ ptr-is_deleted = 1;
+ tomoyo_update_counter(TOMOYO_UPDATES_COUNTER_DOMAIN_POLICY);
+ return 0;
+}
+
+int tomoyo_too_many_domain_acl(struct domain_info * const domain) {
+ unsigned int count = 0;
+ struct acl_info *ptr;
+ for (ptr = domain-first_acl_ptr; ptr; ptr = ptr-next) {
+ if (!ptr-is_deleted) count++;
+ }
+ /* If there are so many entries, don't append if accept mode. */
+ if (count tomoyo_check_flags(TOMOYO_MAX_ACCEPT_ENTRY)) return 0;
+ if (!domain-quota_warned) {
+ printk(TOMOYO-WARNING: Domain '%s' has so many ACLs to hold.
+ Stopped auto-append mode.\n, domain-domainname-name);
+ domain-quota_warned = 1;
+ }
+ return 1;
+}
+
+
+/* DOMAIN INITIALIZER HANDLER
*/
+
+static struct domain_initializer_entry *domain_initializer_list = NULL;
+
+static int
Re: call for more SD versus CFS comparisons (was: Re: Mainline plans)
On 13-06-2007 03:54, Fortier,Vincent [Montreal] wrote: ... Kernels: CFS v16 2.6.21 FC7 build 3194 CK2 2.6.21 FC7 build 3194 ... CFS v16: - beryl interractivity way too unresponsive.. - window decoration highlight taking around 5-10 secs to switch between windows focus - window movement either impossible or animation laggy enough to not being seen at all. - Cube rotation still possible using mouse scroll although really really really laggy Amarok MP3 music: - No audio skips at all. Playing really well! CK2 patchset: - Beryl interractivity almost totally unresponsive... In fact mouse movement was near-impossible to control. - window movement totally impossible - Cube rotation still possible using mouse scroll although there was no animation at all Amarok MP3 music: - Same as CFS, no skips at all. Playing really well! ... Very nice testing! But, maybe it could be even more interesting after adding here the vanilla kernel too, i.e. 2.6.21 FC7 build 3194 without CFS/CK2? Regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thu, Jun 14, 2007 at 03:07:17AM -0300, Alexandre Oliva wrote: On Jun 13, 2007, Adrian Bunk [EMAIL PROTECTED] wrote: If the two courts are in the same country there's usually a higher court above both that can resolve this. But what if let's say the highest court in the USA and the highest court in Germany would disagree on such a matter? Upgrade the license so as to provide guidance as to the intent of the authors, such that the disagreement doesn't happen again. If there's room in each country's laws to fix the problem, that is. I don't think that's an option. Consider the question of whether non-GPL kernel modules are legal at all and the number and different opinions of Linux kernel authors. Plus the general question whether any upgrade the license would be valid in all jurisdictions (GPL version 2 or any later version as licence might make it possible, but in all other cases I'd have serious doubts). cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
Not at all. On an 8641 it could be compatible = fsl,mpc8641-rapidio fsl,mpc8548-rapidio; which states this is the 8641 thing and it is compatible to the 8548 thing. Perfectly clear. The concern is this isn't just compatible = ..8641.. ..8548.. but something like: ..8641.. ..8641d.. ..8548.. ..8548e.. ..8543.. ..8543e.. ..8572.. ..8572e.. ..8567.. ..8567e.. ..8568.. ..8568e.. You don't need to mention _all_ compatible devices in the compatible property, only the few that matter; typically the oldest one, and sometimes some intermediate device that has extra features over the original one. It isn't useful to add compatible entries that no OS probes for. Concrete names are good. While I agree concrete names are good, we put these 'blocks' in so many devices that using the device to match on is pointless. You *definitely* should put the device name for _this_ device in there, in case it needs some special workaround. I'm all for making up a name like 'Grande', 'Del', 'Janeiro'. This is effective what we did with gianfar. The name gets picked up pretty quickly by people. That can be used as the base name, yes. Segher - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: On Jun 13, 2007, Linus Torvalds [EMAIL PROTECTED] wrote: On Wed, 13 Jun 2007, Alexandre Oliva wrote: So, TiVo includes a copy of Linux in its DVR. Stop right there. You seem to make the mistake to think that software is something physical. Err, no. Software, per legal definitions in Brazil, US and elsewhere, require some physical support. That's the hard disk in the TiVO DVR, in this case. I don't see how this matters, though. I'm now intrigued, where are these (Brazilian and US) definitions stipulated, and under what authority? Matt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ioctl disappeared (tty_ioctl)
On Thu, 14 Jun 2007 10:42:23 + Dave Young [EMAIL PROTECTED] wrote:
The kernel reported the messages:
do_ioctl: ioctl c02bff70 disappeared
symbol: tty_ioctl+0x0/0x4e0
[c01813b4] do_ioctl+0x74/0xd0
[c02bff70] tty_ioctl+0x0/0x4e0
[c018159e] vfs_ioctl+0x5e/0x1d0
[c0181787] sys_ioctl+0x77/0x90
[c0104258] syscall_call+0x7/0xb
[c043] __sched_text_start+0x570/0x6c0
===
Right, thanks. This should repair it:
From: Paul Fulghum [EMAIL PROTECTED]
Restore tty locked ioctl handler which was replaced with
an unlocked ioctl handler in hung_up_tty_fops by the patch:
commit e10cc1df1d2014f68a4bdcf73f6dd122c4561f94
Author: Paul Fulghum [EMAIL PROTECTED]
Date: Thu May 10 22:22:50 2007 -0700
tty: add compat_ioctl
This was reported in:
[Bug 8473] New: Oops: 0010 [1] SMP
The bug is caused by switching to hung_up_tty_fops in do_tty_hangup. An
ioctl call can be waiting on BLK after testing for existence of the locked
ioctl handler in the normal tty fops, but before calling the locked ioctl
handler. If a hangup occurs at that point, the locked ioctl fop is NULL
and an oops occurs.
(akpm: we can remove my debugging code from do_ioctl() now, but it'll be OK to
do that for 2.6.23)
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/char/tty_io.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff -puN drivers/char/tty_io.c~tty-restore-locked-ioctl-file-op
drivers/char/tty_io.c
--- a/drivers/char/tty_io.c~tty-restore-locked-ioctl-file-op
+++ a/drivers/char/tty_io.c
@@ -1173,8 +1173,14 @@ static unsigned int hung_up_tty_poll(str
return POLLIN | POLLOUT | POLLERR | POLLHUP | POLLRDNORM | POLLWRNORM;
}
-static long hung_up_tty_ioctl(struct file * file,
- unsigned int cmd, unsigned long arg)
+static int hung_up_tty_ioctl(struct inode * inode, struct file * file,
+unsigned int cmd, unsigned long arg)
+{
+ return cmd == TIOCSPGRP ? -ENOTTY : -EIO;
+}
+
+static long hung_up_tty_compat_ioctl(struct file * file,
+unsigned int cmd, unsigned long arg)
{
return cmd == TIOCSPGRP ? -ENOTTY : -EIO;
}
@@ -1222,8 +1228,8 @@ static const struct file_operations hung
.read = hung_up_tty_read,
.write = hung_up_tty_write,
.poll = hung_up_tty_poll,
- .unlocked_ioctl = hung_up_tty_ioctl,
- .compat_ioctl = hung_up_tty_ioctl,
+ .ioctl = hung_up_tty_ioctl,
+ .compat_ioctl = hung_up_tty_compat_ioctl,
.release= tty_release,
};
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] AHCI Link Power Management
Kristen Carlson Accardi wrote: I'm not sure about this. We need better PM framework to support powersaving in other controllers and some ahcis don't save much when only link power management is used, do you have data to support this? Yeah, it was some Lenovo notebook. Pavel is more familiar with the hardware. Pavel, what was the notebook which didn't save much power with standard SATA power save but needed port to be completely turned off? Thinkpad x60. Some one Kristen probably used while developing the patch :-). Yes - that confirms my conclusion that the first patch just wasn't done correctly - cause when I measure the power savings with a power meter on the X60 with my patches I see ~ 1W. Hmmm... Could it be that the controller doesn't enter powersave state when SControl is written to? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions with patches v3
A Wednesday 13 June 2007 21:35:02, Greg KH escreveu: On Wed, Jun 13, 2007 at 09:58:05PM +0200, Michal Piotrowski wrote: USB Subject: list_add corruption. prev-next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8561 Submitter : Paulo Pereira [EMAIL PROTECTED] Handled-By : Alan Stern [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8561#c8 Status : patch was suggested I'm pretty sure this wasn't a regression and was always there, and that the proposed patch did fix the solution, right Paulo and Alan? thanks, greg k-h No I haven't fix the problem... I'am waiting for a friend that is in holiday's and work's with linux well. I'am beginer in linux and I can't put the patch to work, because of that I'am waiting for him to see if the patch work. Sorry, the fact I don't say anything about the problem but my friend comes this week and them we put the patch and I will tell something!! Regards, Paulo. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ehea: Whitespace cleanup
This patch fixes several whitespace issues.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0f81b5..abaf3ac 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0064
+#define DRV_VERSIONEHEA_0065
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -136,10 +136,10 @@ void ehea_dump(void *adr, int len, char *msg);
(0xULL ((64 - (mask)) 0x))
#define EHEA_BMASK_SET(mask, value) \
-((EHEA_BMASK_MASK(mask) ((u64)(value))) EHEA_BMASK_SHIFTPOS(mask))
+ ((EHEA_BMASK_MASK(mask) ((u64)(value))) EHEA_BMASK_SHIFTPOS(mask))
#define EHEA_BMASK_GET(mask, value) \
-(EHEA_BMASK_MASK(mask) (((u64)(value)) EHEA_BMASK_SHIFTPOS(mask)))
+ (EHEA_BMASK_MASK(mask) (((u64)(value)) EHEA_BMASK_SHIFTPOS(mask)))
/*
* Generic ehea page
@@ -190,7 +190,7 @@ struct ehea_av;
* Queue attributes passed to ehea_create_qp()
*/
struct ehea_qp_init_attr {
-/* input parameter */
+ /* input parameter */
u32 qp_token; /* queue token */
u8 low_lat_rq1;
u8 signalingtype; /* cqe generation flag */
@@ -212,7 +212,7 @@ struct ehea_qp_init_attr {
u64 recv_cq_handle;
u64 aff_eq_handle;
-/* output parameter */
+ /* output parameter */
u32 qp_nr;
u16 act_nr_send_wqes;
u16 act_nr_rwqes_rq1;
@@ -279,12 +279,12 @@ struct ehea_qp {
* Completion Queue attributes
*/
struct ehea_cq_attr {
-/* input parameter */
+ /* input parameter */
u32 max_nr_of_cqes;
u32 cq_token;
u64 eq_handle;
-/* output parameter */
+ /* output parameter */
u32 act_nr_of_cqes;
u32 nr_pages;
};
diff --git a/drivers/net/ehea/ehea_hw.h b/drivers/net/ehea/ehea_hw.h
index 1246757..1af7ca4 100644
--- a/drivers/net/ehea/ehea_hw.h
+++ b/drivers/net/ehea/ehea_hw.h
@@ -211,34 +211,34 @@ static inline void epa_store_acc(struct h_epa epa, u32
offset, u64 value)
}
#define epa_store_eq(epa, offset, value)\
-epa_store(epa, EQTEMM_OFFSET(offset), value)
+ epa_store(epa, EQTEMM_OFFSET(offset), value)
#define epa_load_eq(epa, offset)\
-epa_load(epa, EQTEMM_OFFSET(offset))
+ epa_load(epa, EQTEMM_OFFSET(offset))
#define epa_store_cq(epa, offset, value)\
-epa_store(epa, CQTEMM_OFFSET(offset), value)
+ epa_store(epa, CQTEMM_OFFSET(offset), value)
#define epa_load_cq(epa, offset)\
-epa_load(epa, CQTEMM_OFFSET(offset))
+ epa_load(epa, CQTEMM_OFFSET(offset))
#define epa_store_qp(epa, offset, value)\
-epa_store(epa, QPTEMM_OFFSET(offset), value)
+ epa_store(epa, QPTEMM_OFFSET(offset), value)
#define epa_load_qp(epa, offset)\
-epa_load(epa, QPTEMM_OFFSET(offset))
+ epa_load(epa, QPTEMM_OFFSET(offset))
#define epa_store_qped(epa, offset, value)\
-epa_store(epa, QPEDMM_OFFSET(offset), value)
+ epa_store(epa, QPEDMM_OFFSET(offset), value)
#define epa_load_qped(epa, offset)\
-epa_load(epa, QPEDMM_OFFSET(offset))
+ epa_load(epa, QPEDMM_OFFSET(offset))
#define epa_store_mrmw(epa, offset, value)\
-epa_store(epa, MRMWMM_OFFSET(offset), value)
+ epa_store(epa, MRMWMM_OFFSET(offset), value)
#define epa_load_mrmw(epa, offset)\
-epa_load(epa, MRMWMM_OFFSET(offset))
+ epa_load(epa, MRMWMM_OFFSET(offset))
#define epa_store_base(epa, offset, value)\
-epa_store(epa, HCAGR_OFFSET(offset), value)
+ epa_store(epa, HCAGR_OFFSET(offset), value)
#define epa_load_base(epa, offset)\
-epa_load(epa, HCAGR_OFFSET(offset))
+ epa_load(epa, HCAGR_OFFSET(offset))
static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
{
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9e13433..bdb5241 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(use_mcs, 0:NAPI, 1:Multiple receive
queues, Default = 1 );
static int port_name_cnt = 0;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
-const struct of_device_id *id);
+ const struct of_device_id *id);
static int __devexit ehea_remove(struct ibmebus_dev *dev);
@@ -236,7 +236,7 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe-wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
- | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
+ | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe-sg_list[0].l_key = pr-recv_mr.lkey;
rwqe-sg_list[0].vaddr =
[PATCH]is_power_of_2-ntfs
Replacing (n (n-1)) in the context of power of 2 checks
with is_power_of_2
Signed-off-by: vignesh babu [EMAIL PROTECTED]
---
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index b532a73..8152f79 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -27,6 +27,7 @@
#include linux/pagemap.h
#include linux/quotaops.h
#include linux/slab.h
+#include linux/log2.h
#include aops.h
#include attrib.h
@@ -1574,7 +1575,7 @@ static int ntfs_read_locked_index_inode(struct inode
*base_vi, struct inode *vi)
ntfs_debug(Index collation rule is 0x%x.,
le32_to_cpu(ir-collation_rule));
ni-itype.index.block_size = le32_to_cpu(ir-index_block_size);
- if (ni-itype.index.block_size (ni-itype.index.block_size - 1)) {
+ if (!is_power_of_2(ni-itype.index.block_size)) {
ntfs_error(vi-i_sb, Index block size (%u) is not a power of
two., ni-itype.index.block_size);
goto unm_err_out;
diff --git a/fs/ntfs/logfile.c b/fs/ntfs/logfile.c
index acfed32..53cdb74 100644
--- a/fs/ntfs/logfile.c
+++ b/fs/ntfs/logfile.c
@@ -26,6 +26,7 @@
#include linux/highmem.h
#include linux/buffer_head.h
#include linux/bitops.h
+#include linux/log2.h
#include attrib.h
#include aops.h
@@ -63,9 +64,8 @@ static bool ntfs_check_restart_page_header(struct inode *vi,
logfile_log_page_size = le32_to_cpu(rp-log_page_size);
if (logfile_system_page_size NTFS_BLOCK_SIZE ||
logfile_log_page_size NTFS_BLOCK_SIZE ||
- logfile_system_page_size
- (logfile_system_page_size - 1) ||
- logfile_log_page_size (logfile_log_page_size - 1)) {
+ !is_power_of_2(logfile_system_page_size) ||
+ !is_power_of_2(logfile_log_page_size)) {
ntfs_error(vi-i_sb, $LogFile uses unsupported page size.);
return false;
}
--
Vignesh Babu BM
_
Why is it that every time I'm with you, makes me believe in magic?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH]is_power_of_2-ufs/super.c
Replacing (n (n-1)) in the context of power of 2 checks
with is_power_of_2
Signed-off-by: vignesh babu [EMAIL PROTECTED]
---
diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index 22ff6ed..2b30116 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -87,6 +87,7 @@
#include linux/smp_lock.h
#include linux/buffer_head.h
#include linux/vfs.h
+#include linux/log2.h
#include swab.h
#include util.h
@@ -854,7 +855,7 @@ magic_found:
uspi-s_fmask = fs32_to_cpu(sb, usb1-fs_fmask);
uspi-s_fshift = fs32_to_cpu(sb, usb1-fs_fshift);
- if (uspi-s_fsize (uspi-s_fsize - 1)) {
+ if (!is_power_of_2(uspi-s_fsize)) {
printk(KERN_ERR ufs_read_super: fragment size %u is not a
power of 2\n,
uspi-s_fsize);
goto failed;
@@ -869,7 +870,7 @@ magic_found:
uspi-s_fsize);
goto failed;
}
- if (uspi-s_bsize (uspi-s_bsize - 1)) {
+ if (!is_power_of_2(uspi-s_bsize)) {
printk(KERN_ERR ufs_read_super: block size %u is not a power
of 2\n,
uspi-s_bsize);
goto failed;
--
Vignesh Babu BM
_
Why is it that every time I'm with you, makes me believe in magic?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: udf fs corruption on linux-2.6
Hi Rich,
On Wed 13-06-07 15:48:03, Rich Coe wrote:
This patch fixes directory and missing files corruption in fs/udf which
occurs on all known 2.6 releases.
The corruption occurs because blocks which were pre-alloc'd for a directory
are released back to the fs freelist, but the inode's alloc block information
is not updated to reflect this.
You would not see corruption if the number of files in any directory is
less than 41, because the pre-alloc routine does not allocate blocks for the
directory until the number of files is over 40.
The problem occurs during unmounting because fs/udf incorrectly calls
udf_discard_prealloc() from udf_clear_inode(). udf_discard_prealloc() will
update the inode and schedule it for write, but no write will ever occur
because the fs is in the process of being umount'd.
The solution is to add a put_inode routine to update the inode contents
and release the pre-alloc'd blocks to disk prior to clearing the inode
from the kernel.
Test case:
mkuddfs /dev/scd0
mount -o sync /dev/scd0 /mnt/cdrom
mkdir /mnt/cdrom/A /mnt/cdrom/B
cp A/* /mnt/cdrom/A [ A contains 90 files of various sizes ]
cp B/* /mnt/cdrom/B [ B contains 20 or fewer files ]
umount /mnt/cdrom
Here you can see how 7 blocks starting at sector 139 are free and listed in
the
directory entry for 'A'. I used udfdump to get the following information:
[ ... ]
Free space found on this partition
[0139 - 0159] [0161 - 0191] [0193 - 0223]
[4464 - 4475] [4485 - 00524286] [00524287 - 01048573]
[01048574 - 01572860] [01572861 - 02097147] [02097148 - 02235039]
[ ... ]
Filename `A`
[ ... ]
[ blob at sector 2038 for 2048 bytes in logical partion 0 ]
[ blob at sector 137 for 4096 bytes in logical partion 0 ]
[ blob at sector 139 for14336 bytes in logical partion 0 flags 1
]
--
Rich Coe [EMAIL PROTECTED]
Virtual Principle Engineer General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team
Signed-off-by: Rich Coe [EMAIL PROTECTED]
---
diff -urNp linux-2.6.20.orig/fs/udf/inode.c linux-2.6.20/fs/udf/inode.c
--- linux-2.6.20.orig/fs/udf/inode.c 2007-02-04 12:44:54.0 -0600
+++ linux-2.6.20/fs/udf/inode.c 2007-06-13 11:32:41.930983471 -0500
@@ -102,14 +102,17 @@ no_delete:
void udf_clear_inode(struct inode *inode)
{
+ kfree(UDF_I_DATA(inode));
+ UDF_I_DATA(inode) = NULL;
+}
+
+void udf_put_inode(struct inode *inode)
+{
if (!(inode-i_sb-s_flags MS_RDONLY)) {
lock_kernel();
udf_discard_prealloc(inode);
unlock_kernel();
}
Calling udf_discard_preallloc() from put_inode() has the problem that you
truncate the last extent too early - see the comments in the patch Chuck
pointed too (http://lkml.org/lkml/2007/6/11/79).
Can you try whether that patch fixes your problems?
Thanks
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] Documentation of kernel messages
On Wed, 2007-06-13 at 11:32 -0700, Greg KH wrote:
So, why not use what we already have and work off of it?
dev_printk() and friends are great, since they already define
something
like KMSG_COMPONENT: The driver name.
They provide way more than that, they also provide the explicit device
that is being discussed, as well as other things depending on the
device.
dev_printk() and friends provide additional information for a printk
that is related to a device. Not every printk is about a device, so I
think Michaels proposal is orthorgonal to dev_printk. We definitly
should have a dev_printk variant that uses the kmsg documentation tag
AND we should have a normal printk variant as well that uses the kmsg
tagging.
So if you are going to do this, please use the already-in-place macros
to hook into, don't try to get the driver authors to pick up something
new and different, as it's going to be _very_ difficult, trust me...
There is no doubt that it will be difficult to get a larger part of the
developers use the kmsg scheme (e.g. see the reaction of Dave M.). We do
not have the illusion that we can replace every single message in the
kernel, nor do we think that it would make sense to do so. What we would
do for s390 is to check each message in drivers/s390 and think hard if
the message should be 1) removed, 2) replaced with a {dev_}printk_kmsg
or 3) left as it is. Fortunatly for us there are not too many drivers
for s390 ..
--
blue skies,
Martin.
Reality continues to ruin my life. - Calvin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 22:14, Krzysztof Halasa wrote: It seems so. But it has this upgrade option, and one possible interpretation of ^^ Linus' comment is no, it doesn't have this update option. It? What it? I don't get it. If you say the licence is v2 only, then how can it have options? By section 9. The license is v2, and basically allows to update the license - and it makes this a choice of the user (who also has rights to change stuff and redistribute it). If I use GPL as license, I'm under GPL regime, i.e. the terms of the GPL apply. First, the local and international laws apply. It's not like selling your soul to the devil. Contract law means that first and foremost the contract itself defines the rules, and only if it is not or contradicts the law, the law jumps in. The GPL is not really a contract, it's a license, but the law is not much different here, especially once you accept the GPL. If you put your code under GPL, the text in the GPL is the deal. The law is only the framework under which the deal works. If you accept the M$ EULA, international law still applies, yet you are selling your soul to the devil (because the EULA sais so). Now, I may rewrite those few GPLv2 only files, and then I have a GPLv2-or later compatible linux-some.version-bp kernel. Sure, you can rewrite all non GPLv2 or later code and have v3 Linux. The problem is you think only few files are v2. Because only few files say so, and they must say what they mean, because GPL is rather clear that if you put a file which doesn't say which version applies under GPL, it's any GPL. Why is it so difficult to grok section 9 of the current GPLv2, which people claim is well understood? A number of kernel hacker deliberately want their work under GPLv2 only (like Al Viro), and they are fully entitled to do that - but they must announce it in a propper place (not lkml or lwn.org), and a comment in COPYING signed by Linus Torvalds doesn't seem to be propper to me, especially when the GPLv2 gives a procedure how to do it (look for the appendix: How to Apply These Terms to Your New Programs). There are good reasons to follow the advice there, and those who did follow the advice in the Linux kernel in the vast majority said GPLv2 or later. Verbatim copy without understanding? Or is it rather that the other people who didn't follow the advice didn't read the GPL, and therefore understand it even less ;-)? -- Bernd Paysan If you want it done right, you have to do it yourself http://www.jwdt.com/~paysan/ pgpAehWNc0zDy.pgp Description: PGP signature
mach64 breakage in 2.6.22
On Sat, May 05, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ +atyfb-reorganize-clock-init.patch This change breaks the display on an ibook1 with 800x600 lcd. It is commit b4e124c138558a0cff51398ddff9a8e44ed0b529 in 2.6.22-rc4. The used config is arch/powerpc/configs/pmac32_defconfig It seems that the recognized display width is only 640, the remain space up to 800 is repeated with the content from colum 0. The chars around colum 640 are mostly garbage. . atyfb: using auxiliary register aperture atyfb: 3D RAGE Mobility L (Mach64 LN, AGP 2x) [0x4c4e rev 0x64] atyfb: 4M SDRAM (2:1) (32-bit), 14.31818 MHz XTAL, 230 MHz PLL, 70 Mhz MCLK, 27 MHz XCLK aty: Backlight initialized (atybl0) atyfb: monitor sense=0, mode 20 Console: switching to colour frame buffer device 100x37 atyfb: fb0: ATY Mach64 frame buffer device on PCI . Using PowerMac machine description Total memory = 160MB; using 512kB for hash table (at c9f8) Linux version 2.6.22-rc4-git5 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #10 Thu Jun 14 09:40:21 CEST 2007 Found initrd at 0xc410:0xc435e000 Found UniNorth memory controller host bridge @ 0xf800 revision: 0x03 Mapped at 0xfdfc Found a Keylargo mac-io controller, rev: 2, mapped at 0xfdf4 PowerMac motherboard: iBook (first generation) via-pmu: Server Mode is disabled PMU driver v2 initialized for Core99, firmware: 0c Entering add_active_range(0, 0, 40960) 0 entries of 256 used Found UniNorth PCI host bridge at 0xf000. Firmware bus number: 0-0 Found UniNorth PCI host bridge at 0xf200. Firmware bus number: 0-0 Found UniNorth PCI host bridge at 0xf400. Firmware bus number: 0-0 nvram: Checking bank 0... nvram: gen0=549, gen1=548 nvram: Active bank is: 0 nvram: OF partition at 0x210 nvram: XP partition at 0x nvram: NR partition at 0x Top of RAM: 0xa00, Total RAM: 0xa00 Memory hole size: 0MB Zone PFN ranges: DMA 0 -40960 Normal 40960 -40960 early_node_map[1] active PFN ranges 0:0 -40960 On node 0 totalpages: 40960 DMA zone: 320 pages used for memmap DMA zone: 0 pages reserved DMA zone: 40640 pages, LIFO batch:7 Normal zone: 0 pages used for memmap Built 1 zonelists. Total pages: 40640 Kernel command line: root=/dev/disk/by-label/mango_root quiet sysrq=1 panic=42 mpic: Setting up MPIC MPIC 1version 1.2 at 8004, max 4 CPUs mpic: ISU size: 64, shift: 6, mask: 3f mpic: Initializing for 64 sources PID hash table entries: 1024 (order: 10, 4096 bytes) GMT Delta read from XPRAM: 0 minutes, DST: on time_init: decrementer frequency = 16.644884 MHz time_init: processor frequency = 299.97 MHz Console: colour dummy device 80x25 console handover: boot [udbg0] - real [tty0] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 154564k/163840k available (4168k kernel code, 9120k reserved, 168k data, 150k bss, 204k init) Calibrating delay loop... 33.15 BogoMIPS (lpj=66304) Mount-cache hash table entries: 512 device-tree: Duplicate name in /cpus/PowerPC,[EMAIL PROTECTED], renamed to l2-cache#1 NET: Registered protocol family 16 KeyWest i2c @0xf8001003 irq 42 /[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus multibus channel 1 bus multibus KeyWest i2c @0x80018000 irq 26 /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus multibus PMU i2c /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 1 bus multibus channel 2 bus multibus PCI: Probing PCI hardware PCI: Cannot allocate resource region 0 of device 0001:10:19.0 Apple USB OHCI 0001:10:19.0 disabled by firmware SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 2424k freed io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered PCI: Enabling device :00:10.0 (0086 - 0087) atyfb: using auxiliary register aperture atyfb: 3D RAGE Mobility L (Mach64 LN, AGP 2x) [0x4c4e rev 0x64] atyfb: 4M SDRAM (2:1) (32-bit), 14.31818 MHz XTAL, 230 MHz PLL, 70 Mhz MCLK, 27 MHz XCLK aty: Backlight initialized (atybl0) atyfb: monitor sense=0, mode 20 Console: switching to colour frame buffer device 100x37 atyfb: fb0: ATY Mach64 frame buffer device on PCI Generic RTC Driver v1.07 Macintosh non-volatile memory driver v1.1 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024
Re: [kvm-devel] [BUG] Oops with KVM-27
Luca Tettamanti wrote:
With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
using xchg. With !GOOD_APIC and this patch:
--- include/asm-i386/apic.h~2007-04-26 05:08:32.0 +0200
+++ include/asm-i386/apic.h 2007-06-13 22:35:00.0 +0200
@@ -56,7 +56,8 @@
static __inline fastcall void native_apic_write_atomic(unsigned long reg,
unsigned long v)
{
- xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+// xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+ *((volatile unsigned long *)(APIC_BASE+reg)) = v;
}
static __inline fastcall unsigned long native_apic_read(unsigned long reg)
The kernel boots fine.
Looking at the xchg emulation code, it seems fine, but clearly it
isn't. Can you add logging to the kernel apic driver and to the qemu
device emulation (qemu/hw/apic.c, apic_mem_readl()/apic_mem_writel())
and compare the results?
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 03:11:45 Alexandre Oliva wrote: On Jun 14, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 01:51:13 Alexandre Oliva wrote: On Jun 14, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote: In 95% of the desktop computers, you can't make changes to the OS that runs on it. Whom is this good for? Faulty logic. I have yet to find a computer that I couldn't change the OS on. I was not talking about installing another OS, I was talking about making changes to the OS. As in, improving one particular driver, avoiding a blue screen, stuff like that. Ah, well... In the case of Windos and other proprietary OS's I try to educate people and get them to switch. Good. So I presume you'd tell them to switch away from a turned-proprietary GNU/Linux operating system as well, right? If that happened I'd be lost. I've tried the various BSD's and found they had problems with hardware support and getting a new version of the BSD kernel to compile and boot is something of a black art. The point is moot, though. It can never happen. So, again, what do we gain if companies abuse the GPL and disrespect users' rights that we meant them to respect? Or do you mean transferring the recorded copies off the TiVO and on to a different medium? Sure. Such that I can watch shows while wasting time in public transportation, in an airplane, whatever. Under the US Copyright law I'm not sure that making a second copy like that is legal. IIRC, Fair Use only allows for one copy. Even if you delete the first copy? Actually, I thought fair use in US entitled you to make a backup copy. So the copy in your TiVO would be your original, and the external copy would be your fair-use backup. Hrm... Perhaps. As has been noted in their TOS and the licenses for the hardware from the start. If it is used to disrespect the inalienable freedoms associated with the GPL software in the device, it seems like a license violation to me. As much as the US Declaration of Independence and other sources want people to believe otherwise there is no such thing as inalienable rights or inalienable freedoms. In this case I have been unable to find this inalienable freedom to run custom versions of software on the same machine that you received the original copy on anywhere before the GPLv3 - and even then it isn't explicitly clear. There is no restriction on your right to modify, copy, distribute or run the software as provided by versions of the GPL prior to version 3. If this run modified copies on the same hardware you received the original on *IS* the spirit of the license, then why isn't it stated anywhere before GPLv3? (After all, the FSF has have 20+ years to mention it) The FSF itself explicitly reserves the right to change the GPL at any time - which is no different. Actually, it's completely different. If the FSF revises the GPL, the old version remains available for anyone to use for any new software, and all software released under the old version remains available under that old version. I'll grant you that. But, at this point, where can I find a copy of the GPLv1 without having to dig around the net ? In contrast, your TiVO may get a software upgrade without your permission that will take your rights away from that point on, and there's very little you can do about it, other than unplugging it from the network to avoid the upgrade if it's not too late already. And because its a device that connects to their network - and TiVO isn't a telecommunications company - they have the right to upgrade and configure the software inside however they want. (In the US at least) A lot of them would probably have private modifications that would never be distributed - and under the GPLv2 it is clear that you can keep modifications private as long as you don't distribute them. Likewise with GPLv3. I can see this, but will a company see this? Pushing them away means that they'd not do that because they would be concerned that the license will change under them in such a way that even those private modifications need to be released to the public. This would not only change the spirit of the license, but turn it into a non-Free Software license. Point. But once again - would a company pay attention to that fact? And then, again, the license can't possibly be changed from under them. A new revision of the GPL would only affect software licensed under that new revision. If you already got it under an earlier revision, you know what you got, and nobody can take that away from you. True. But that doesn't save them from lawsuits trying to force them to obey the terms of the new revision even though they received the software under an earlier version. (and don't try to argue that even though those modifications are truly private (to
Re: [RFC/PATCH] Documentation of kernel messages
On Wed, 2007-06-13 at 11:15 -0700, Andrew Morton wrote: Your proposal is similar to one I made to some Japanese developers earlier this year. Interesting. Our requirement comes from Japan as well. I was more modest, proposing that we - add an enhanced printk xxprintk(msgid, KERN_ERR some text %d\n, some_number); Some kind of id is always required to be able to identify the message. The task is to make the tagging as simple as possible. - An externally managed database will provide translations, diagnostics, remedial actions, etc, keyed off the msgid string There I have my doubts if this can work. If you keep an external database with the additional information about the messages the kernel code and the database will get out of sync. Thats why we advocate the kernel-doc style approach: the message catalogue will always be in sync because it is delivered with the kernel. - Format and management of the msgid hasn't been clearly identified yet as far as I know. But all we really need is that each ID be unique, kernel-wide. We develop a simple tool which can check the whole tree for duplicated msgids. This is a paint point with Michaels approach as well. The KMSG_COMPONENT defines are rather ugly. A clever way how to generate kernel unique IDs would be nice. Intervention required.. - From a practical day-to-day POV what this means is that a person from the kernel-messages team will prepare a patch for your driver which adds the msgids and you the driver author should take care not to break the tagging. This is deliberately designed to be minimum-impact upon general developers. We want a system in place where driver/fs/etc developers can concentrate on what they do, and kernel-message developers can as independently as possibe take care of what _they_ do. With the KMSG approach all that needs to be done is to replace the KERN_xxx with KMSG_xxx(number) and to add a comment at the end of the file. - A project has started up and there is a mailing list (cc'ed here) and meetings are happening at the LF collaboration summit this week. Please see https://lists.linux-foundation.org/mailman/listinfo/lf_kernel_messages and don't miss the next conference call ;) (argh. The lf_kernel_messages archives are subscriber-only and it could be that only members can post to it. Oh well. Please subscribe, and review the archives) Very interesting. We did not know about this project. Thanks for the hint. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 01:49, Alexandre Oliva wrote: Oh, good, let's take this one. if you distribute copies of such a program, [...] you must give the recipients all the rights that you have So, TiVo includes a copy of Linux in its DVR. TiVo retains the right to modify that copy of Linux as it sees fit. It doesn't give the recipients the same right. Oops. Sounds like a violation of the spirit to me. Sounds like plugging this hole would retain the same spirit. Note that Harald Welte has already managed to force Siemens to unlock a tivoized Linux router with the GPLv2 in Germany. German contract law values intention when the contract has no specific clause that deals with the issue, and in German law, an accepted license is a contract. So the fact that tivoizing Linux is against the spirit of the GPLv2 is a court-proof fact, not just some speculation. What about if your GPL program ends up in a piece of hardware (e.g. a ROM, or an embedded ROM, or if it's some GPL code from OpenCores, as gate netlist in silicon)? My interpretation is that you need a permission from the author for doing that, unless there's an easy way to replace it with a modified copy (e.g. if you put the OpenCores stuff into an FPGA, replacing the configuration PROM would do it). Some people have difficulties with intentions of contracts rather than direct rules. That may be due to different rules in different countries. In continental Europe, contract law usually bases on Code Napoleon, and there, good faith is an important principle (and good faith means that the intention is more important than the actual coded practices). In the roman law that was used before and has survived in countries who didn't let Napoleon in (like the UK and the USA), it's slightly different. But a contract or a license still is not a program where anything that isn't said explicitely isn't said at all. -- Bernd Paysan If you want it done right, you have to do it yourself http://www.jwdt.com/~paysan/ pgpzwPBHF6QnS.pgp Description: PGP signature
Re: [PATCH]: add parameter struct bin_attribute * in .read/.write methods for sysfs binary attributes
On Wed, Jun 13, 2007 at 09:35:44PM -0400, Len Brown wrote: I've applied this to acpi-test with an Acked-by: gregkh -- as we need it for the acpi table patch. Greg, unless I hear from you, I'll assume that this is okay for 2.6.23. It's fine with me, you can add a real: Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] to it too. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wed, 2007-06-13 at 23:38 -0300, Alexandre Oliva wrote: On Jun 13, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote: Exactly. They don't. What TiVO prevents is using that modified version on their hardware. And they have that right, because the Hardware *ISN'T* ^^ BTW as soon as I bought that thing, it is *my* hardware and no longer *theirs* (whoever theirs was). covered by the GPL. Indeed, TiVO has this legal right. But then they must not use Do they? At least in .at, it is usually impossible to (legally) limit the rights of the *owner* a (tangible) thing (and if I bought it, I *am* the owner and no one else) - even if you put it in the sales contract since this is discussion about/within sales law. One usual example is you buy a car and neither the car producer nor the (re)seller can restrict the brands of the tires you may use or the brand of the fuel etc.. And the same holds for pretty much everything. No one can forbid you to open a TV set and fix it (or let it fix by whoever I choose to). Yes, there are exceptions in several laws for specific things (e.g. for really dangerous ones like airbags in cars) but in general, you are allowed to do almost anything (including the simple destruction of it). And yes, if you *rent* the thing, you are not the owner and this is a totally different thing. software under the GPLv3 in it. And, arguably, they must not use software under the GPLv2 either. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On Wed, 2007-06-13 at 23:23 -0700, Ollie Wild wrote:
On 6/13/07, Luck, Tony [EMAIL PROTECTED] wrote:
Above 5Mbytes, I started seeing problems. The line/word/char
counts from wc started being 0 0 0. Not sure if this is
a problem in wc dealing with a single line 5MBytes, or some
other problem (possibly I was exceeding the per-process stack
limit which is only 8MB on that machine).
Interesting. If you're exceeding your stack ulimit, you should be
seeing either an argument list too long message or getting a
SIGSEGV. Have you tried bypassing wc and piping the output straight
to a file?
I think it sends SIGKILL on failure paths.
I've been thinking of moving this large stack alloc in
create_elf_tables() before the point of no return.
something like this, it should do the largest part of the alloc
beforehand. Just have to see if all binfmts need this much, and if not,
what the ramifications are of overgrowing the stack (perhaps we need to
shrink it again to wherever bprm-p ends up?)
Index: linux-2.6-2/fs/exec.c
===
--- linux-2.6-2.orig/fs/exec.c 2007-06-14 10:29:22.0 +0200
+++ linux-2.6-2/fs/exec.c 2007-06-14 10:28:45.0 +0200
@@ -272,6 +272,17 @@ static bool valid_arg_len(struct linux_b
return len = MAX_ARG_STRLEN;
}
+static int expand_arg_vma(struct linux_binprm *bprm)
+{
+ long size = (bprm-argc + bprm-envc + 2) * sizeof(void *);
+
+#ifdef CONFIG_STACK_GROWSUP
+#error I broke it
+#else
+ return expand_stack(bprm-vma, bprm-p - size);
+#endif
+}
+
#else
static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
@@ -326,6 +337,11 @@ static bool valid_arg_len(struct linux_b
return len = bprm-p;
}
+static int expand_arg_vma(struct linux_binprm *bprm)
+{
+ return 0;
+}
+
#endif /* CONFIG_MMU */
/*
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm-argv_len = env_p - bprm-p;
+ retval = expand_arg_vma(bprm);
+ if (retval 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval = 0) {
/* execve success */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Theodore Tso wrote: Basically, in the US, you get the best justice money can buy. :-) that has to be one of the best one-liners ever! :) - Ted -jb -- Tact is the art of making a point without making an enemy. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] libata IT821X driver still fails! Hard-freezes system.
This is the screen image I took with my digital camera when bootup freezes: http://spherevision.org/sync/visual/itefreeze.jpg After this freeze, not even SysRq commands work. On a side-note, the non-libata drivers boot up, but throw tons of DMA errors after one DVD burn. The kernel I tested this on (newest I would try) is 2.6.22-rc4 with and without cfs16. I am willing to test out patches if I can get this darn controller working. My config: http://spherevision.org/sync/tmp/dot.config At the time of this freeze, the kernel was not tainted. I am running a Pentium-D 830 3.0GHz Dualcore on a ASUS P5LD2 with latest bios rev. 1804. My lspci -vvv info: http://spherevision.org/sync/tmp/lspci.out I also find it pecular that it says there is a 40wire cable; I have tried 3 different 80wire cables and it doesn't make a difference. So, yes indeed I am using proper cables, and have tried others. Just to make sure, this a brand new 20A1P burner, the old one did the same thing though. If I build pata_821x(or whatnot) as a module, system freezes after about 5 seconds after insmod, without dumping any information at all. It may say it's a RAID controller, but on this motherboard it seems to be pure passthru because there is no RAID option for this controller in the BIOS. I have also tried a few flags recommended by Alan before, which do not help. Help would be very much appreciated! Further info, if needed, just ask. -r - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] Documentation of kernel messages
Hi, holzheu [EMAIL PROTECTED] writes: If the information is to big for the printk itself, because you would need 10 lines to explain what happened, wouldn't it be good to have a place where to put that information? I think if a message really has to be 10 lines long to be clear then it should just be 10 lines long. The keyword is really. Example: oops. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 04:37:55 Bernd Petrovitsch wrote: On Wed, 2007-06-13 at 23:38 -0300, Alexandre Oliva wrote: On Jun 13, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote: Exactly. They don't. What TiVO prevents is using that modified version on their hardware. And they have that right, because the Hardware *ISN'T* ^^ BTW as soon as I bought that thing, it is *my* hardware and no longer *theirs* (whoever theirs was). eh. Perhaps I should have said that differently. And TiVO could handle it differently. I'm not going to argue about it anymore. It's pointless. covered by the GPL. Indeed, TiVO has this legal right. But then they must not use Do they? At least in .at, it is usually impossible to (legally) limit the rights of the *owner* a (tangible) thing (and if I bought it, I *am* the owner and no one else) - even if you put it in the sales contract since this is discussion about/within sales law. One usual example is you buy a car and neither the car producer nor the (re)seller can restrict the brands of the tires you may use or the brand of the fuel etc.. No argument there. However, that is not to say that you bought it, now you're free to do with it whatever you please is always what the law says (at least in the US) In the TiVO case there may be restrictions placed on the manufacturer for legal reasons or contractual reasons. Seeing as I'm not privy to the contracts between TiVO and the various production and broadcasting companies I can't comment on what contracts they have. As to the legal side there are restrictions in copyright law. And the same holds for pretty much everything. No one can forbid you to open a TV set and fix it (or let it fix by whoever I choose to). I know of at least one company that will sell you the parts to repair your TV if its out of warranty. DRH Yes, there are exceptions in several laws for specific things (e.g. for really dangerous ones like airbags in cars) but in general, you are allowed to do almost anything (including the simple destruction of it). And yes, if you *rent* the thing, you are not the owner and this is a totally different thing. software under the GPLv3 in it. And, arguably, they must not use software under the GPLv2 either. Bernd -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/03] kbuild, asm-values: infrastructure
On Thu, Jun 14, 2007 at 09:41:43AM +0200, Oleg Verych wrote: Jun 13, 2007 at 01:36:51AM +0200, asm-values patch set: * header with widely used value definitions * handle all asm-related things in one file (Makefile.asm) * move some asm bits from Makefile.build there (rule %.s:%.c) * add script to generate headers from assembles output (hopefully better output, MIPS testing/joining to all arch probably needed) rfc-by: Oleg Verych --- So, is it another not so juicy lets-break-it-all stuff from me, or it just doesn't apply for you? I have not yet looked at it. A few other items pending that I need to finish off before next merge window has priority. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] fallocate() implementation in i86, x86_64 and powerpc
On Jun 14, 2007 09:52 +1000, David Chinner wrote:
B FA_PREALLOCATE
provides the same functionality as
B FA_ALLOCATE
except it does not ever change the file size. This allows allocation
of zero blocks beyond the end of file and is useful for optimising
append workloads.
TP
B FA_DEALLOCATE
removes the underlying disk space with the given range. The disk space
shall be removed regardless of it's contents so both allocated space
from
B FA_ALLOCATE
and
B FA_PREALLOCATE
as well as from
B write(3)
will be removed.
B FA_DEALLOCATE
shall never remove disk blocks outside the range specified.
So this is essentially the same as punch. There doesn't seem to be
a mechanism to only unallocate unused FA_{PRE,}ALLOCATE space at the
end.
B FA_DEALLOCATE
shall never change the file size. If changing the file size
is required when deallocating blocks from an offset to end
of file (or beyond end of file) is required,
B ftuncate64(3)
should be used.
This also seems to be a bit of a wart, since it isn't a natural converse
of either of the above functions. How about having two modes,
similar to FA_ALLOCATE and FA_PREALLOCATE? Say, FA_PUNCH (which
would be as you describe here - deletes all data in the specified
range changing the file size if it overlaps EOF, and FA_DEALLOCATE,
which only deallocates unused FA_{PRE,}ALLOCATE space?
We might also consider making @mode be a mask instead of an enumeration:
FA_FL_DEALLOC 0x01 (default allocate)
FA_FL_KEEP_SIZE 0x02 (default extend/shrink size)
FA_FL_DEL_DATA 0x04 (default keep written data on DEALLOC)
We might then build FA_ALLOCATE and FA_DEALLOCATE out of these flags
without making the interface sub-optimal.
I suppose it might be a bit late in the game to add a goal
parameter and e.g. FA_FL_REQUIRE_GOAL, FA_FL_NEAR_GOAL, etc to make
the API more suitable for XFS? The goal could be a single __u64, or
a struct with e.g. __u64 byte offset (possibly also __u32 lun like
in FIEMAP). I guess the one potential limitation here is the
number of function parameters on some architectures.
B ENOSPC
There is not enough space left on the device containing the file
referred to by
IR fd.
Should probably say whether space is removed on failure or not. In
some (primitive) implementations it might no longer be possible to
distinguish between unwritten extents and zero-filled blocks, though
at this point DEALLOC of zero-filled blocks might not be harmful either.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 09:32, Paul Mundt wrote: This is perhaps the part that's the most interesting. For the very small number of people that _do_ want to change these things (usually at the expense of a voided warranty, in the consumer device case), there's always a way to make these changes, even if you must resort to hardware hacking. Trying to mandate this sort of functionality in the license might make it easier for a few people to get their code loaded, but the vast majority of users have zero interest in anything like this. I don't feel this is a very conclusive argument. How many computer users do want to change their OS? I mean not only want to change the OS in the sense of apply patches released by Microsoft, but on their own? Many typical computer users ask for help to fix their computer when turning it off and on again already fixes it. They would never ever change the source code of their OS even if they technically could do it - they are not programmers. However, if there is the technical possibility to change the firmware of an appliance, somebody does it, and often mere users upload these changes to their own device (like the OpenWRT stuff). Let me give one example: My parents own a DVB-T DVR. It was a cheap one, and it was cheap because the software is lackluster. Unfortunately it isn't free. Many users of this device complain to the manufacturer about the stability and quality of the software, but with no avail - there haven't been any updates in the last two years. I suppose I would be able to fix the problem, most other users probably wouldn't (and my parents neither). But if I did fix the problem, and provided them with an updated firmware, they would install it on their device. That's the help your neighbour right in the GNU manifesto. It's as important as the help yourself right, maybe even more. It was the original motivation of RMS to make free software - the frustration of not being able to help his neighbours. He had an NDA to help himself. What people want is software that works. If the firmware of your microwave or DVR works, you don't care so much if it is free or not. You only care if it doesn't work, and you feel the urge to fix it (and turning it off and on again doesn't fix it). That's why people complain loud about ATI drivers not being open, and don't care that much about the Nvidia driver, which is just as closed, but works. -- Bernd Paysan If you want it done right, you have to do it yourself http://www.jwdt.com/~paysan/ pgpBnogBxibSw.pgp Description: PGP signature
[TOMOYO 3/9] Data structures and prototypes definition.
This is prototypes and structures definition.
Many of structures are single-linked list and memory allocated for them are
never freed,
because entries used for access control needn't to be removed from the list so
frequently
compared to general other entries in the kernel. This saves the amount of
memory needed by TOMOYO.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/include/tomoyo.h | 319
+++
1 file changed, 319 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/include/tomoyo.h
linux-2.6.21.5-tomoyo/security/tomoyo/include/tomoyo.h
--- linux-2.6.21.5/security/tomoyo/include/tomoyo.h 1970-01-01
09:00:00.0 +0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/include/tomoyo.h 2007-06-05
00:00:00.0 +0900
@@ -0,0 +1,319 @@
+/*
+ * security/tomoyo/include/tomoyo.h
+ *
+ * Implementation of the Domain-Based Mandatory Access Control.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ *
+ */
+#ifndef _TOMOYO_H
+#define _TOMOYO_H
+
+#include linux/string.h
+#include linux/mm.h
+#include linux/utime.h
+#include linux/file.h
+#include linux/smp_lock.h
+#include linux/module.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/poll.h
+#include asm/uaccess.h
+#include stdarg.h
+#include linux/delay.h
+
+/* TOMOYO Linux start. */
+
+struct tomoyo_security {
+ struct domain_info *domain_info;
+ u32 flags;
+};
+
+struct path_info {
+ const char *name;
+ u32 hash;/* = full_name_hash(name, strlen(name)) */
+ u16 total_len; /* = strlen(name) */
+ u16 const_len; /* = tomoyo_const_part_length(name)*/
+ u8 is_dir; /* = tomoyo_strendswith(name, /) */
+ u8 is_patterned; /* = PathContainsPattern(name) */
+ u16 depth; /* = tomoyo_path_depth(name)*/
+};
+
+#define TOMOYO_MAX_PATHNAME_LEN 4000
+
+struct group_member {
+ struct group_member *next;
+ const struct path_info *member_name;
+ int is_deleted;
+};
+
+struct group_entry {
+ struct group_entry *next;
+ const struct path_info *group_name;
+ struct group_member *first_member;
+};
+
+/*
+ * TOMOYO uses the following structures.
+ * Memory allocated for these structures are never kfree()ed.
+ * Since no locks are used for reading, assignment must be performed
atomically.
+ */
+
+/* The structure for domains.
*/
+
+struct acl_info {
+ struct acl_info *next;
+ u8 type;
+ u8 is_deleted;
+ union {
+ u16 w;
+ u8 b[2];
+ } u;
+};
+
+struct domain_info {
+ struct domain_info *next; /* Pointer to next record. NULL if
none. */
+ struct acl_info *first_acl_ptr; /* Pointer to first acl. NULL if
none. */
+ const struct path_info *domainname; /* Name of this domain. Never NULL.
*/
+ u8 profile; /* Profile to use.
*/
+ u8 is_deleted; /* Delete flag.
*/
+ u8 quota_warned;/* Quota warnning done flag.
*/
+};
+
+#define TOMOYO_MAX_PROFILES 256
+
+struct file_acl_record {
+ struct acl_info head; /* type = TOMOYO_TYPE_FILE_ACL, b[0] = perm, b[1]
= u_is_group */
+ union {
+ const struct path_info *filename; /* Pointer to single
pathname. */
+ const struct group_entry *group;/* Pointer to pathname
group. */
+ } u;
+};
+
+struct single_acl_record {
+ struct acl_info head; /* type = TOMOYO_TYPE_*, w =
u_is_group */
+ union {
+ const struct path_info *filename; /* Pointer to single
pathname. */
+ const struct group_entry *group; /* Pointer to pathname group.
*/
+ } u;
+};
+
+struct double_acl_record {
+ /* type = TOMOYO_TYPE_RENAME_ACL or TOMOYO_TYPE_LINK_ACL, */
+ /* b[0] = u1_is_group, b[1] = u2_is_group */
+ struct acl_info head;
+ union {
+ const struct path_info *filename1; /* Pointer to single
pathname. */
+ const struct group_entry *group1; /* Pointer to pathname
group. */
+ } u1;
+ union {
+ const struct path_info *filename2; /* Pointer to single
pathname. */
+ const struct group_entry *group2; /* Pointer to pathname
group. */
+ } u2;
+};
+
+/* Keywords for ACLs. */
+
+#define TOMOYO_KEYWORD_AGGREGATOR aggregator
+#define TOMOYO_KEYWORD_AGGREGATOR_LEN
(sizeof(TOMOYO_KEYWORD_AGGREGATOR) - 1)
+#define TOMOYO_KEYWORD_ALIASalias
+#define TOMOYO_KEYWORD_ALIAS_LEN
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton [EMAIL PROTECTED] writes: Exactly. And I don't see anything about a TiVO (or any device that, like a TiVO, requires binaries that run on it to be digitally signed) that stops you from exercising the freedoms guaranteed by the GPL. As I said before, what it does is stop you from violating the license on the hardware. BTW: don't they sell their hardware (as well)? I think it should be easy to replace the ROMs (EPROMs? flash ROMs?) using some diagnostic clip and/or JTAG. Unless the CPU itself verifies ROM signatures, they shouldn't matter. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 03:24, Adrian Bunk wrote: Harald is in Germany, and he therefore takes legal action against people distributing products violating his copyright on the Linux kernel in Germany at German courts based on German laws. And if Tivo did sell their crap in Germany, I bet, Harald had brought them down years ago (as he did in the tivoized Siemens router case). But Tivo doesn't (they started in the UK, and stopped doing so right after Harald unlocked that Siemens router ;-), and in the US, courts may think different. Or they rely that there simply is no Harald Welte in the US, who goes after the violators. -- Bernd Paysan If you want it done right, you have to do it yourself http://www.jwdt.com/~paysan/ pgpYtKZDs0RqT.pgp Description: PGP signature
Re: mm: Fix memory/cpu hotplug section mismatch and oops.
Thanks. I tested compile with cpu/memory hotplug off/on.
It was OK.
Acked-by: Yasunori Goto [EMAIL PROTECTED]
(This is a resend of the earlier patch, this issue still needs to be
fixed.)
When building with memory hotplug enabled and cpu hotplug disabled, we
end up with the following section mismatch:
WARNING: mm/built-in.o(.text+0x4e58): Section mismatch: reference to
.init.text: (between 'free_area_init_node' and '__build_all_zonelists')
This happens as a result of:
- free_area_init_node()
- free_area_init_core()
- zone_pcp_init() -- all __meminit up to this point
- zone_batchsize() -- marked as __cpuinit
fo
This happens because CONFIG_HOTPLUG_CPU=n sets __cpuinit to __init, but
CONFIG_MEMORY_HOTPLUG=y unsets __meminit.
Changing zone_batchsize() to __devinit fixes this.
__devinit is the only thing that is common between CONFIG_HOTPLUG_CPU=y and
CONFIG_MEMORY_HOTPLUG=y. In the long run, perhaps this should be moved to
another section identifier completely. Without this, memory hot-add
of offline nodes (via hotadd_new_pgdat()) will oops if CPU hotplug is
not also enabled.
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
--
mm/page_alloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index bd8e335..05ace44 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1968,7 +1968,7 @@ void zone_init_free_lists(struct pglist_data *pgdat,
struct zone *zone,
memmap_init_zone((size), (nid), (zone), (start_pfn), MEMMAP_EARLY)
#endif
-static int __cpuinit zone_batchsize(struct zone *zone)
+static int __devinit zone_batchsize(struct zone *zone)
{
int batch;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Yasunori Goto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva [EMAIL PROTECTED] writes: BTW, what license is Linux licensed under? It's GPLv2 plus userland exception, right? (There's some additional module exception, right?) Pure GPLv2. Userland exception? Never heard of. Module exception? Perhaps you mean interpretation? -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: On Jun 14, 2007, Bron Gondwana [EMAIL PROTECTED] wrote: Tivo gets sick of the endless flamewars on lkml, signs a copy of QNX, pushes it out to the hardware. No more Linux on Tivo. What do we lose? Do we actually get any benefit whatsoever from TiVO's choice of Linux as the kernel for its device? Do they contribute back any code that makes Linux better? If Tivo doesn't, what about other vendors who may be in a similar situation? Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata and legacy ide pcmcia failure
Albert Lee wrote: libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't cover nodata commands tho). Hi Tejun, Polling of nodata commands was fixed in: http://marc.info/?l=linux-idem=116546272916399w=2 Right. Thanks for reminding me. :-) -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] Documentation of kernel messages
snip Your proposal is similar to one I made to some Japanese developers earlier this year. I was more modest, proposing that we - add an enhanced printk xxprintk(msgid, KERN_ERR some text %d\n, some_number); Maybe a stupid idea but why do we want to assign these numbers by hand? I can imagine it could introduce collisions when merging tons of patches with new messages... Wouldn't it be better to compute say, 8-byte hash from the message and use it as it's identifier? We could do this automagically at compile time. I know it also has it's problems - you fix a spelling and the message gets a different id and you have to update translation/documentation catalogue but maybe that could be solved too... Honza - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Runaway process and oom-killer
Helge Hafting wrote: John Sigler wrote: Andrea Arcangeli wrote: On Wed, Jun 13, 2007 at 10:49:29AM +0200, John Sigler wrote: Question 2: how can I tell which process or kernel thread was hogging most of the RAM when the oom-killer kicked in? Theoretically the one that was killed first but not for sure in current mainline hence see below. If I read the logs correctly, oom-killer is invoked three times before it effectively kills a process. Then oom-killer kills myapp, syslogd, and boa, in that order. Why didn't oom-killer kill anything the first three times? My guess: Something needs memory but finds there is none to be had oom-killer is invoked and targets myapp. myapp takes some time to die. Particularly, the memory it uses isn't freed up instantly. In the meantime something else needs memory and find none. (Another packet received?) Possibly. In fact, myapp receives a 40 Mbit/s stream. The oom-killer is invoked again, this time it targets syslogd. I went hunting, and found a memory leak in our syslogd. Doh! And so on. The kernel do many things in parallel, running out of memory in a multitasking system therefore is a complicated business. Especially when process killing takes some time. I didn't mention that there is no swap on this system. Note that you can turn off memory overcommit, your leaky app should then get a memory allocation error instead of triggering the oom-killer. Are you referring to these /proc/sys/vm entries? # cat /proc/sys/vm/overcommit_memory 0 # cat /proc/sys/vm/overcommit_ratio 50 Are you suggesting I set overcommit_memory to 2? The manual states: /proc/sys/vm/overcommit_memory This file contains the kernel virtual memory accounting mode. Values are: 0: heuristic overcommit (this is the default) 1: always overcommit, never check 2: always check, never overcommit In mode 0, calls of mmap(2) with MAP_NORESERVE set are not checked, and the default check is very weak, leading to the risk of getting a process OOM-killed. Under Linux 2.4 any non-zero value implies mode 1. In mode 2 (available since Linux 2.6), the total virtual address space on the system is limited to (SS + RAM*(r/100)), where SS is the size of the swap space, and RAM is the size of the physical memory, and r is the contents of the file /proc/sys/vm/overcommit_ratio. In my case, SS=0 and RAM=256MB. If I understand correctly, if I set ratio to 50, then processes can only address 128MB. I'd be, in effect, reserving 128MB for the kernel, right? Are there other entries in /proc/sys/vm I should be playing with? :-) /proc/sys/vm/block_dump 0 /proc/sys/vm/dirty_background_ratio 10 /proc/sys/vm/dirty_expire_centisecs 3000 /proc/sys/vm/dirty_ratio 40 /proc/sys/vm/dirty_writeback_centisecs 500 /proc/sys/vm/drop_caches 0 /proc/sys/vm/laptop_mode 0 /proc/sys/vm/legacy_va_layout 0 /proc/sys/vm/lowmem_reserve_ratio 256 /proc/sys/vm/max_map_count 65536 /proc/sys/vm/min_free_kbytes 2039 /proc/sys/vm/nr_pdflush_threads 2 /proc/sys/vm/overcommit_memory 0 /proc/sys/vm/overcommit_ratio 50 /proc/sys/vm/page-cluster 3 /proc/sys/vm/panic_on_oom 0 /proc/sys/vm/percpu_pagelist_fraction 0 /proc/sys/vm/swappiness 60 /proc/sys/vm/vdso_enabled 1 /proc/sys/vm/vfs_cache_pressure 100 Regards. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 1/9] Allow use of namespace_sem from LSM module.
TOMOYO Linux uses pathnames for auditing and controlling file access. Therefore, namespace_sem is needed. Signed-off-by: Kentaro Takeda [EMAIL PROTECTED] Signed-off-by: Tetsuo Handa [EMAIL PROTECTED] --- fs/namespace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -ubBpErN linux-2.6.21.5/fs/namespace.c linux-2.6.21.5-tomoyo/fs/namespace.c --- linux-2.6.21.5/fs/namespace.c 2007-06-12 03:37:06.0 +0900 +++ linux-2.6.21.5-tomoyo/fs/namespace.c2007-06-14 15:02:38.0 +0900 @@ -37,7 +37,7 @@ static int event; static struct list_head *mount_hashtable __read_mostly; static int hash_mask __read_mostly, hash_bits __read_mostly; static struct kmem_cache *mnt_cache __read_mostly; -static struct rw_semaphore namespace_sem; +struct rw_semaphore namespace_sem; /* /sys/fs */ decl_subsys(fs, NULL, NULL); --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 2/9] Kconfig and Makefile for TOMOYO Linux.
TOMOYO Linux 2.0 is implemented using LSM and auditing subsystem. When you use TOMOYO, you need to enable auditing support and disable all features (other than TOMOYO Linux) that use LSM because TOMOYO Linux 2.0 has to be built-in. If you don't want to disable any features that use LSM, please use TOMOYO Linux 1.4.1 instead. Signed-off-by: Kentaro Takeda [EMAIL PROTECTED] Signed-off-by: Tetsuo Handa [EMAIL PROTECTED] --- security/Kconfig |1 + security/Makefile|1 + security/tomoyo/Kconfig | 22 ++ security/tomoyo/Makefile |3 +++ 4 files changed, 27 insertions(+) diff -ubBpErN linux-2.6.21.5/security/Kconfig linux-2.6.21.5-tomoyo/security/Kconfig --- linux-2.6.21.5/security/Kconfig 2007-06-12 03:37:06.0 +0900 +++ linux-2.6.21.5-tomoyo/security/Kconfig 2007-06-14 15:02:38.0 +0900 @@ -94,6 +94,7 @@ config SECURITY_ROOTPLUG If you are unsure how to answer this question, answer N. source security/selinux/Kconfig +source security/tomoyo/Kconfig endmenu diff -ubBpErN linux-2.6.21.5/security/Makefile linux-2.6.21.5-tomoyo/security/Makefile --- linux-2.6.21.5/security/Makefile2007-06-12 03:37:06.0 +0900 +++ linux-2.6.21.5-tomoyo/security/Makefile 2007-06-14 15:02:38.0 +0900 @@ -16,3 +16,4 @@ obj-$(CONFIG_SECURITY)+= security.o d obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o +obj-$(CONFIG_SECURITY_TOMOYO) += tomoyo/ diff -ubBpErN linux-2.6.21.5/security/tomoyo/Kconfig linux-2.6.21.5-tomoyo/security/tomoyo/Kconfig --- linux-2.6.21.5/security/tomoyo/Kconfig 1970-01-01 09:00:00.0 +0900 +++ linux-2.6.21.5-tomoyo/security/tomoyo/Kconfig 2007-06-05 00:00:00.0 +0900 @@ -0,0 +1,22 @@ +config SECURITY_TOMOYO + bool TOMOYO Linux support + depends on SECURITY AUDIT + help + Say Y here to support TOMOYO Linux. + + TOMOYO Linux is applicable to figuring out the system's behavior, + for TOMOYO uses the canonicalized absolute pathnames and + TreeView style domain transitions. + +config TOMOYO_MAX_ACCEPT_ENTRY + int Default maximal count for accept mode + default 2048 + range 0 2147483647 + depends on SECURITY_TOMOYO + help + This is the default value for maximal ACL entries + that are automatically appended into policy at accept mode. + Some programs access thousands of objects, so running + such programs in accept mode dulls the system response + and consumes much memory. + This is the safeguard for such programs. diff -ubBpErN linux-2.6.21.5/security/tomoyo/Makefile linux-2.6.21.5-tomoyo/security/tomoyo/Makefile --- linux-2.6.21.5/security/tomoyo/Makefile 1970-01-01 09:00:00.0 +0900 +++ linux-2.6.21.5-tomoyo/security/tomoyo/Makefile 2007-06-05 00:00:00.0 +0900 @@ -0,0 +1,3 @@ +obj-$(CONFIG_SECURITY_TOMOYO) += tomoyo.o tomoyo_func.o +tomoyo_func-objs := domain.o common.o realpath.o file.o audit.o +EXTRA_CFLAGS += -Isecurity/tomoyo/include --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 4/9] LSM adapter for TOMOYO.
This file contains wrapper functions for TOMOYO's file access control functions.
The main job is to find struct vfsmount that corresponds to struct dentry
passed to LSM hooks.
Since struct vfsmount is not passed to LSM hooks,
TOMOYO can't determine which pathnames was requested by the process
if bind mounts are used.
If bind mounts are used, TOMOYO requires all permissions for
all possible pathnames (whereas AppArmor requires one of possible pathnames).
If struct vfsmount is passed to LSM hooks as AppArmor proposes,
this file will become more simpler and namespace_sem can remain static.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/tomoyo.c | 283
+++
1 file changed, 283 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/tomoyo.c
linux-2.6.21.5-tomoyo/security/tomoyo/tomoyo.c
--- linux-2.6.21.5/security/tomoyo/tomoyo.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/tomoyo.c 2007-06-14
15:11:57.0 +0900
@@ -0,0 +1,283 @@
+/*
+ * security/tomoyo/tomoyo.c
+ *
+ * LSM hooks for TOMOYO Linux.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/security.h
+#include linux/highmem.h
+#include linux/namei.h
+#include linux/mnt_namespace.h
+#include linux/sysctl.h
+#include linux/proc_fs.h
+#include linux/sched.h
+
+#include tomoyo.h
+
+/* The initial domain. */
+struct domain_info KERNEL_DOMAIN = { NULL, NULL, NULL, 0, 0, 0 };
+extern struct rw_semaphore namespace_sem;
+
+static struct kmem_cache *tomoyo_cachep = NULL;
+
+static int tomoyo_task_alloc_security(struct task_struct *p)
+{
+ struct tomoyo_security *ptr = kmem_cache_alloc(tomoyo_cachep,
GFP_KERNEL);
+ if (!ptr)
+ return -ENOMEM;
+ memcpy(ptr, current-security, sizeof(*ptr));
+ p-security = ptr;
+ return 0;
+}
+
+static void tomoyo_task_free_security(struct task_struct *p)
+{
+ kmem_cache_free(tomoyo_cachep, p-security);
+}
+
+static int tomoyo_bprm_alloc_security(struct linux_binprm *bprm)
+{
+ bprm-security = ((struct tomoyo_security *)
current-security)-domain_info;
+ return 0;
+}
+
+static int tomoyo_bprm_check_security(struct linux_binprm * bprm)
+{
+ struct domain_info *next_domain = NULL;
+ int retval = 0;
+ extern void tomoyo_load_policy(const char *filename);
+ extern int tomoyo_find_next_domain(struct linux_binprm *, struct
domain_info **);
+ tomoyo_load_policy(bprm-filename);
+ if (!(((struct tomoyo_security *) current-security)-flags
+ TOMOYO_CHECK_READ_FOR_OPEN_EXEC)) {
+ retval = tomoyo_find_next_domain(bprm, next_domain);
+ if (retval == 0) {
+ ((struct tomoyo_security *)
current-security)-domain_info = next_domain;
+ ((struct tomoyo_security *) current-security)-flags |=
+ TOMOYO_CHECK_READ_FOR_OPEN_EXEC;
+ }
+ }
+
+ return retval;
+}
+
+static void tomoyo_bprm_post_apply_creds(struct linux_binprm * bprm)
+{
+ bprm-security = ((struct tomoyo_security *)
current-security)-domain_info;
+}
+
+static void tomoyo_bprm_free_security(struct linux_binprm * bprm)
+{
+ ((struct tomoyo_security *) current-security)-domain_info =
+ (struct domain_info *) bprm-security;
+ ((struct tomoyo_security *) current-security)-flags =
+ ~TOMOYO_CHECK_READ_FOR_OPEN_EXEC;
+}
+
+static int tomoyo_inode_permission(struct inode *inode, int mask, struct
nameidata *nd)
+{
+ int flag = 0;
+ if (S_ISDIR(inode-i_mode)) /* ignore because inode is directory */
+ return 0;
+ if (!nd || !nd-dentry || !nd-mnt)
+ return 0;
+ if ((mask == MAY_EXEC) (((struct tomoyo_security *)
current-security)-flags
+ TOMOYO_CHECK_READ_FOR_OPEN_EXEC))
+ mask = MAY_READ;
+ if ((mask == MAY_EXEC) || (mask == 0))
+ return 0;
+
+ if (mask == (MAY_READ | MAY_EXEC)) {
+ flag |= O_RDONLY + 1;
+ } else {
+ if (mask MAY_READ)
+ flag |= O_RDONLY + 1;
+ if (mask MAY_WRITE)
+ flag |= O_WRONLY + 1;
+ if ((mask MAY_APPEND))
+ flag |= O_APPEND;
+ }
+ return tomoyo_check_open_permission(nd-dentry, nd-mnt, flag);
+}
+
+static int tomoyo_do_check_single_write_permission(int operation, struct
dentry *dentry)
+{
+ struct mnt_namespace *namespace = current-nsproxy-mnt_ns;
+ struct list_head *p;
+ int ret = 0, error = 0;
+ int index = 0, index2 = 0;
+ if (!dentry || !namespace)
+
[patch] sched: fix SysRq-N (normalize RT tasks)
From: Ingo Molnar [EMAIL PROTECTED]
Subject: [patch] sched: fix SysRq-N (normalize RT tasks)
Gene Heskett reported the following problem while testing CFS: SysRq-N
is not always effective in normalizing tasks back to SCHED_OTHER.
the reason for that turns out to be the following bug:
normalize_rt_tasks() uses for_each_process() to iterate through all
tasks in the system. The problem is, this method does not iterate
through all tasks, it iterates through all thread groups. The proper
mechanism to enumerate all tasks is to use a do_each_thread() +
while_each_thread() loop.
obvious bugfix for v2.6.22 inclusion. -stable candidate as well.
Reported-by: Gene Heskett [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
kernel/sched.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Index: linux/kernel/sched.c
===
--- linux/kernel/sched.c
+++ linux/kernel/sched.c
@@ -7071,12 +7071,13 @@ EXPORT_SYMBOL(__might_sleep);
void normalize_rt_tasks(void)
{
struct prio_array *array;
- struct task_struct *p;
+ struct task_struct *g, *p;
unsigned long flags;
struct rq *rq;
read_lock_irq(tasklist_lock);
- for_each_process(p) {
+
+ do_each_thread(g, p) {
if (!rt_task(p))
continue;
@@ -7094,7 +7095,8 @@ void normalize_rt_tasks(void)
__task_rq_unlock(rq);
spin_unlock_irqrestore(p-pi_lock, flags);
- }
+ } while_each_thread(g, p);
+
read_unlock_irq(tasklist_lock);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + fs-introduce-write_begin-write_end-and-perform_write-aops.patch added to -mm tree
On Wed, 2007-06-13 at 13:43 +0200, Nick Piggin wrote: .. 5) ext3_write_end: Before write_begin/write_end patch set we have folowing locking order: stop_journal(handle); unlock_page(page); But now order is oposite: unlock_page(page); stop_journal(handle); Can we got any race condition now? I'm not sure is it actual problem, may be somebody cant describe this. Can we just change it to the original order? That would seem to be safest unless one of the ext3 devs explicitly acks it. Sorry, I've missed beginning of this thread. But what problems can exactly cause this ordering change? ext3_journal_stop has no need to be protected by the page lock - it can be even better that it's not protected as it can trigger commit and all that would happen unnecessarily under page lock... Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 5/9] Memory and pathname management functions.
We limit the maximum length of any string data (such as domainname and
pathnames)
to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page.
Userland programs can obtain the amount of RAM currently used by TOMOYO from
/proc interface.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/include/realpath.h | 46 +
security/tomoyo/realpath.c | 445
+
2 files changed, 491 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/include/realpath.h
linux-2.6.21.5-tomoyo/security/tomoyo/include/realpath.h
--- linux-2.6.21.5/security/tomoyo/include/realpath.h 1970-01-01
09:00:00.0 +0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/include/realpath.h2007-06-05
00:00:00.0 +0900
@@ -0,0 +1,46 @@
+/*
+ * security/tomoyo/include/realpath.h
+ *
+ * Get the canonicalized absolute pathnames. The basis for TOMOYO.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ *
+ */
+
+#ifndef _TOMOYO_REALPATH_H
+#define _TOMOYO_REALPATH_H
+
+struct path_info;
+
+/* Returns realpath(3) of the given pathname but ignores chroot'ed root. */
+int tomoyo_realpath_from_dentry2(struct dentry *dentry,
+ struct vfsmount *mnt,
+ char *newname,
+ int newname_len);
+
+/* Returns realpath(3) of the given pathname but ignores chroot'ed root. */
+/* These functions use tomoyo_alloc(), so caller must tomoyo_free() */
+/* if these functions didn't return NULL. */
+char *tomoyo_realpath(const char *pathname);
+char *tomoyo_realpath_nofollow(const char *pathname);
+char *tomoyo_realpath_from_dentry(struct dentry *dentry, struct vfsmount *mnt);
+
+/* Allocate memory for structures. */
+/* The RAM is chunked, so NEVER try to kfree() the returned pointer. */
+void *tomoyo_alloc_element(const unsigned int size);
+
+/* Get used RAM size for tomoyo_alloc_elements(). */
+unsigned int tomoyo_get_memory_used_for_elements(void);
+
+/* Keep the given name on the RAM. */
+/* The RAM is shared, so NEVER try to modify or kfree() the returned name. */
+const struct path_info *tomoyo_save_name(const char *name);
+
+/* Get used RAM size for tomoyo_save_name(). */
+unsigned int tomoyo_get_memory_used_for_save_name(void);
+
+unsigned int tomoyo_get_memory_used_for_dynamic(void);
+
+#endif
diff -ubBpErN linux-2.6.21.5/security/tomoyo/realpath.c
linux-2.6.21.5-tomoyo/security/tomoyo/realpath.c
--- linux-2.6.21.5/security/tomoyo/realpath.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/realpath.c2007-06-14
15:06:37.0 +0900
@@ -0,0 +1,445 @@
+/*
+ * security/tomoyo/realpath.c
+ *
+ * Get the canonicalized absolute pathnames.
+ * The basis for TOMOYO Linux.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include linux/string.h
+#include linux/mm.h
+#include linux/utime.h
+#include linux/file.h
+#include linux/smp_lock.h
+#include linux/module.h
+#include linux/slab.h
+#include asm/uaccess.h
+#include asm/atomic.h
+#include linux/namei.h
+#include linux/mount.h
+#include linux/proc_fs.h
+#include realpath.h
+#include tomoyo.h
+
+extern int sbin_init_started;
+
+/* realpath handler */
+
+/*
+ * tomoyo_get_absolute_path - return the path of a dentry but ignores
chroot'ed root.
+ * @dentry: dentry to report
+ * @vfsmnt: vfsmnt to which the dentry belongs
+ * @buffer: buffer to return value in
+ * @buflen: buffer length
+ *
+ * Caller holds the dcache_lock.
+ * Based on __d_path() in fs/dcache.c
+ *
+ * If dentry is a directory, trailing '/' is appended.
+ * Characters other than ' ' c 127 are converted to \ooo style octal
string.
+ * Character \ is converted to \\ string.
+ */
+static int tomoyo_get_absolute_path(struct dentry *dentry,
+struct vfsmount *vfsmnt,
+char *buffer,
+int buflen)
+{
+ char *start = buffer;
+ char *end = buffer + buflen;
+ int is_dir = (dentry-d_inode S_ISDIR(dentry-d_inode-i_mode));
+
+ if (buflen 256) goto out;
+
+ *--end = '\0';
+ buflen--;
+
+ for (;;) {
+ struct dentry *parent;
+
+ if (dentry == vfsmnt-mnt_root || IS_ROOT(dentry)) {
+ /* Global root? */
+ spin_lock(vfsmount_lock);
+ if (vfsmnt-mnt_parent == vfsmnt) {
+ spin_unlock(vfsmount_lock);
+ break;
+ }
+ dentry = vfsmnt-mnt_mountpoint;
+ vfsmnt = vfsmnt-mnt_parent;
+ spin_unlock(vfsmount_lock);
+ continue;
+ }
+ if (is_dir) {
+
[TOMOYO 6/9] Utility functions and /proc interface for policy manipulation.
This file contains utility functions for TOMOYO.
Any string data in TOMOYO Linux consists with ASCII printable characters (0x21
to 0x7E)
so that userland application can separate monotonically using whitespaces and
carrige returns.
Any wildcard character consists with \ + one ASCII printable character,
so that wildcard characters can be expanded without changing existing names.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/common.c | 1576
+++
1 file changed, 1576 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/common.c
linux-2.6.21.5-tomoyo/security/tomoyo/common.c
--- linux-2.6.21.5/security/tomoyo/common.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/common.c 2007-06-05
00:00:00.0 +0900
@@ -0,0 +1,1576 @@
+/*
+ * security/tomoyo/common.c
+ *
+ * Common functions for TOMOYO Linux.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include linux/string.h
+#include linux/mm.h
+#include linux/utime.h
+#include linux/file.h
+#include linux/module.h
+#include linux/slab.h
+#include asm/uaccess.h
+#include stdarg.h
+#include linux/namei.h
+#include linux/mount.h
+#include linux/proc_fs.h
+#include realpath.h
+#include tomoyo.h
+
+#if defined (CONFIG_TOMOYO_MAX_ACCEPT_ENTRY)
+#define MAX_ACCEPT_ENTRY (CONFIG_TOMOYO_MAX_ACCEPT_ENTRY)
+#else
+#define MAX_ACCEPT_ENTRY 2048
+#endif
+
+static int tomoyo_read_control(struct file *file, char __user *buffer, const
int buffer_len);
+
+/* VARIABLES */
+
+/* /sbin/init started? */
+int sbin_init_started = 0;
+
+const char *ccs_log_level = KERN_DEBUG;
+
+static struct {
+ const char *keyword;
+ unsigned int current_value;
+ const unsigned int max_value;
+} ccs_control_array[TOMOYO_MAX_CONTROL_INDEX] = {
+ [TOMOYO_PROFILE_COMMENT] = { COMMENT, 0, 0 }, /*
Reserved for string. */
+ [TOMOYO_MAC_FOR_FILE]= { MAC_FOR_FILE,0, 3 },
+ [TOMOYO_MAX_ACCEPT_ENTRY]= { MAX_ACCEPT_ENTRY,
MAX_ACCEPT_ENTRY, INT_MAX },
+ [TOMOYO_VERBOSE] = { TOMOYO_VERBOSE, 1, 1 },
+ [TOMOYO_ALLOW_ENFORCE_GRACE] = { ALLOW_ENFORCE_GRACE, 0, 1 },
+};
+
+struct profile {
+ unsigned int value[TOMOYO_MAX_CONTROL_INDEX];
+ const struct path_info *comment;
+};
+
+static struct profile *profile_ptr[TOMOYO_MAX_PROFILES];
+
+/* UTILITY FUNCTIONS */
+
+static int tomoyo_quiet_setup(char *str)
+{
+ ccs_control_array[TOMOYO_VERBOSE].current_value = 0;
+ return 0;
+}
+
+__setup(TOMOYO_QUIET, tomoyo_quiet_setup);
+
+/* Am I root? */
+static int tomoyo_is_root(void)
+{
+ return !current-uid !current-euid;
+}
+
+/*
+ * Format string.
+ * Leading and trailing whitespaces are removed.
+ * Multiple whitespaces are packed into single space.
+ */
+static void tomoyo_normalize_line(unsigned char *buffer)
+{
+ unsigned char *sp = buffer, *dp = buffer;
+ int first = 1;
+ while (*sp (*sp = ' ' || *sp = 127)) sp++;
+ while (*sp) {
+ if (!first) *dp++ = ' ';
+ first = 0;
+ while (*sp ' ' *sp 127) *dp++ = *sp++;
+ while (*sp (*sp = ' ' || *sp = 127)) sp++;
+ }
+ *dp = '\0';
+}
+
+/*
+ * Check whether the given filename follows the naming rules.
+ * Returns nonzero if follows, zero otherwise.
+ */
+int tomoyo_is_correct_path(const char *filename,
+ const int start_type,
+ const int pattern_type,
+ const int end_type,
+ const char *function)
+{
+ int contains_pattern = 0;
+ char c, d, e;
+ const char *original_filename = filename;
+ if (!filename) goto out;
+ c = *filename;
+ if (start_type == 1) { /* Must start with '/' */
+ if (c != '/') goto out;
+ } else if (start_type == -1) { /* Must not start with '/' */
+ if (c == '/') goto out;
+ }
+ if (c) c = * (strchr(filename, '\0') - 1);
+ if (end_type == 1) { /* Must end with '/' */
+ if (c != '/') goto out;
+ } else if (end_type == -1) { /* Must not end with '/' */
+ if (c == '/') goto out;
+ }
+ while ((c = *filename++) != '\0') {
+ if (c == '\\') {
+ switch ((c = *filename++)) {
+ case '\\': /* \\ */
+ continue;
+ case '$': /* \$ */
+ case '+': /* \+ */
+ case '?': /* \? */
+ case '*': /* \* */
+ case '@': /* \@ */
+ case 'x': /* \x */
+
[patch 3/6] SM501: Fix sm501_init_reg() mask/set order
The order of the set and mask operation in sm501_init_reg() was setting and then masking the bits set. Correct the order so that we do not end up with 288MHz SDRAM clocks on certain systems. Signed-off-by: Ben Dooks [EMAIL PROTECTED] Index: linux-2.6.21-quilt8/drivers/mfd/sm501.c === --- linux-2.6.21-quilt8.orig/drivers/mfd/sm501.c2007-06-07 12:13:03.0 +0100 +++ linux-2.6.21-quilt8/drivers/mfd/sm501.c 2007-06-07 12:13:06.0 +0100 @@ -803,6 +803,9 @@ static DEVICE_ATTR(dbg_regs, 0666, sm501 /* sm501_init_reg * * Helper function for the init code to setup a register + * + * clear the bits which are set in r-mask, and then set + * the bits set in r-set. */ static inline void sm501_init_reg(struct sm501_devdata *sm, @@ -812,8 +815,8 @@ static inline void sm501_init_reg(struct unsigned long tmp; tmp = readl(sm-regs + reg); - tmp |= r-set; tmp = ~r-mask; + tmp |= r-set; writel(tmp, sm-regs + reg); } -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/6] SM501: initialise SDRAM clock before bus clocks
This init sequence of setting the SDRAM clock before the
bus clock is recommend by Silicon Motion to stop problems
with writes not sticking into registers.
Signed-off-by: Vincent Sanders [EMAIL PROTECTED]
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.21-quilt8/drivers/mfd/sm501.c
===
--- linux-2.6.21-quilt8.orig/drivers/mfd/sm501.c2007-06-07
12:12:38.0 +0100
+++ linux-2.6.21-quilt8/drivers/mfd/sm501.c 2007-06-07 12:13:03.0
+0100
@@ -833,15 +833,15 @@ static void sm501_init_regs(struct sm501
sm501_init_reg(sm, SM501_GPIO31_0_CONTROL, init-gpio_low);
sm501_init_reg(sm, SM501_GPIO63_32_CONTROL, init-gpio_high);
- if (init-mclk) {
- dev_info(sm-dev, setting MCLK to %ld\n, init-mclk);
- sm501_set_clock(sm-dev, SM501_CLOCK_MCLK, init-mclk);
- }
-
if (init-m1xclk) {
dev_info(sm-dev, setting M1XCLK to %ld\n, init-m1xclk);
sm501_set_clock(sm-dev, SM501_CLOCK_M1XCLK, init-m1xclk);
}
+
+ if (init-mclk) {
+ dev_info(sm-dev, setting MCLK to %ld\n, init-mclk);
+ sm501_set_clock(sm-dev, SM501_CLOCK_MCLK, init-mclk);
+ }
}
static unsigned int sm501_mem_local[] = {
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 4/6] SM501: Clock updates and checks
Ensure that the M1XCLK and MCLK are sourced from
the same PLL (and refuse to bind the driver if they
are not).
Update the PCI to safe initialisation values, as 72MHz
is the maximum clock for 33MHz PCI bus mastering.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.21-quilt8/drivers/mfd/sm501.c
===
--- linux-2.6.21-quilt8.orig/drivers/mfd/sm501.c2007-06-07
12:42:22.0 +0100
+++ linux-2.6.21-quilt8/drivers/mfd/sm501.c 2007-06-07 13:01:02.0
+0100
@@ -845,6 +845,24 @@ static void sm501_init_regs(struct sm501
dev_info(sm-dev, setting MCLK to %ld\n, init-mclk);
sm501_set_clock(sm-dev, SM501_CLOCK_MCLK, init-mclk);
}
+
+}
+
+/* Check the PLL sources for the M1CLK and M1XCLK
+ *
+ * If the M1CLK and M1XCLKs are not sourced from the same PLL, then
+ * there is a risk (see errata AB-5) that the SM501 will cease proper
+ * function. If this happens, then it is likely the SM501 will
+ * hang the system.
+*/
+
+static int sm501_check_clocks(struct sm501_devdata *sm)
+{
+ unsigned long pwrmode = readl(sm-regs + SM501_CURRENT_CLOCK);
+ unsigned long msrc = (pwrmode SM501_POWERMODE_M_SRC);
+ unsigned long m1src = (pwrmode SM501_POWERMODE_M1_SRC);
+
+ return ((msrc == 0 m1src != 0) || (msrc == 0 msrc != 0));
}
static unsigned int sm501_mem_local[] = {
@@ -901,6 +919,12 @@ static int sm501_init_dev(struct sm501_d
}
}
+ ret = sm501_check_clocks(sm);
+ if (ret) {
+ dev_err(sm-dev, M1X and M clocks sourced from different
PLLs\n);
+ return -EINVAL;
+ }
+
/* always create a framebuffer */
sm501_register_display(sm, mem_avail);
@@ -1034,8 +1058,12 @@ static struct sm501_initdata sm501_pci_i
},
.devices= SM501_USE_ALL,
- .mclk = 100 * MHZ,
- .m1xclk = 160 * MHZ,
+
+ /* Errata AB-3 says that 72MHz is the fastest available
+* for 33MHZ PCI with proper bus-mastering operation */
+
+ .mclk = 72 * MHZ,
+ .m1xclk = 144 * MHZ,
};
static struct sm501_platdata_fbsub sm501_pdata_fbsub = {
Index: linux-2.6.21-quilt8/include/linux/sm501-regs.h
===
--- linux-2.6.21-quilt8.orig/include/linux/sm501-regs.h 2007-06-07
12:41:34.0 +0100
+++ linux-2.6.21-quilt8/include/linux/sm501-regs.h 2007-06-07
12:42:22.0 +0100
@@ -64,6 +64,11 @@
#define SM501_DEBUG_CONTROL(0x34)
/* power management */
+#define SM501_POWERMODE_P2X_SRC(129)
+#define SM501_POWERMODE_V2X_SRC(120)
+#define SM501_POWERMODE_M_SRC (112)
+#define SM501_POWERMODE_M1_SRC (14)
+
#define SM501_CURRENT_GATE (0x38)
#define SM501_CURRENT_CLOCK(0x3C)
#define SM501_POWER_MODE_0_GATE(0x40)
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/6] SM501 fixes and updates
A set of fixes and documentation updates for the drivers/mfd/sm501.c SM501 driver -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 5/6] SM501: Add Documentation/SM501.txt
Add documentation for the SM501 in Documentation/SM501.txt outlining the SM501 driver. Signed-off-by: Ben Dooks [EMAIL PROTECTED] Index: linux-2.6.21-quilt8/Documentation/SM501.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.21-quilt8/Documentation/SM501.txt 2007-06-13 13:12:04.0 +0100 @@ -0,0 +1,66 @@ + SM501 Driver + + +Copyright 2006, 2007 Simtec Electronics + +Core + + +The core driver in drivers/mfd provides common services for the +drivers which manage the specific hardware blocks. These services +include locking for common registers, clock control and resource +management. + +The core registers drivers for both PCI and generic bus based +chips via the platform device and driver system. + +On detection of a device, the core initialises the chip (which may +be specified by the platform data) and then exports the selected +peripheral set as platform devices for the specific drivers. + +The core re-uses the platform device system as the platform device +system provides enough features to support the drivers without the +need to create a new bus-type and the associated code to go with it. + + +Resources +- + +Each peripheral has a view of the device which is implicitly narrowed to +the specific set of resources that peripheral requires in order to +function correctly. + +The centralised memory allocation allows the driver to ensure that the +maximum possible resource allocation can be made to the video subsystem +as this is by-far the most resource-sensitive of the on-chip functions. + +The primary issue with memory allocation is that of moving the video +buffers once a display mode is chosen. Indeed when a video mode change +occurs the memory footprint of the video subsystem changes. + +Since video memory is difficult to move without changing the display +(unless sufficient contiguous memory can be provided for the old and new +modes simultaneously) the video driver fully utilises the memory area +given to it by aligning fb0 to the start of the area and fb1 to the end +of it. Any memory left over in the middle is used for the acceleration +functions, which are transient and thus their location is less critical +as it can be moved. + + +Configuration +- + +The platform device driver uses a set of platform data to pass +configurations through to the core and the subsidiary drivers +so that there can be support for more than one system carrying +an SM501 built into a single kernel image. + +The PCI driver assumes that the PCI card behaves as per the Silicon +Motion reference design. + +There is an errata (AB-5) affecting the selection of the +of the M1XCLK and M1CLK frequencies. These two clocks +must be sourced from the same PLL, although they can then +be divided down individually. If this is not set, then SM501 may +lock and hang the whole system. The driver will refuse to +attach if the PLL selection is different. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 6/6] SM501: Check SM501 ID register on initialisation
When binding the driver, check the ID register for a valid
identity, in case the SM501 is not functioning correctly.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.21-quilt8/drivers/mfd/sm501.c
===
--- linux-2.6.21-quilt8.orig/drivers/mfd/sm501.c2007-06-13
11:33:55.0 +0100
+++ linux-2.6.21-quilt8/drivers/mfd/sm501.c 2007-06-13 12:59:31.0
+0100
@@ -883,6 +883,7 @@ static int sm501_init_dev(struct sm501_d
{
resource_size_t mem_avail;
unsigned long dramctrl;
+ unsigned long devid;
int ret;
mutex_init(sm-clock_lock);
@@ -890,13 +891,18 @@ static int sm501_init_dev(struct sm501_d
INIT_LIST_HEAD(sm-devices);
- dramctrl = readl(sm-regs + SM501_DRAM_CONTROL);
+ devid = readl(sm-regs + SM501_DEVICEID);
+ if ((devid SM501_DEVICEID_IDMASK) != SM501_DEVICEID_SM501) {
+ dev_err(sm-dev, incorrect device id %08lx\n, devid);
+ return -EINVAL;
+ }
+
+ dramctrl = readl(sm-regs + SM501_DRAM_CONTROL);
mem_avail = sm501_mem_local[(dramctrl 13) 0x7];
- dev_info(sm-dev, SM501 At %p: Version %08x, %ld Mb, IRQ %d\n,
-sm-regs, readl(sm-regs + SM501_DEVICEID),
-(unsigned long)mem_avail 20, sm-irq);
+ dev_info(sm-dev, SM501 At %p: Version %08lx, %ld Mb, IRQ %d\n,
+sm-regs, devid, (unsigned long)mem_avail 20, sm-irq);
sm501_dump_gate(sm);
Index: linux-2.6.21-quilt8/include/linux/sm501-regs.h
===
--- linux-2.6.21-quilt8.orig/include/linux/sm501-regs.h 2007-06-13
11:33:55.0 +0100
+++ linux-2.6.21-quilt8/include/linux/sm501-regs.h 2007-06-13
11:33:56.0 +0100
@@ -109,6 +109,9 @@
#define SM501_DEVICEID (0x60)
/* 0x050100A0 */
+#define SM501_DEVICEID_SM501 (0x0501)
+#define SM501_DEVICEID_IDMASK (0x)
+
#define SM501_PLLCLOCK_COUNT (0x64)
#define SM501_MISC_TIMING (0x68)
#define SM501_CURRENT_SDRAM_CLOCK (0x6C)
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/6] SM501: suspend support
This patch adds support for suspending the core
(mfd driver) of the SM501.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.21-quilt8/drivers/mfd/sm501.c
===
--- linux-2.6.21-quilt8.orig/drivers/mfd/sm501.c2007-06-04
16:06:29.0 +0100
+++ linux-2.6.21-quilt8/drivers/mfd/sm501.c 2007-06-13 13:25:50.0
+0100
@@ -41,6 +41,9 @@ struct sm501_devdata {
struct resource *regs_claim;
struct sm501_platdata *platdata;
+ unsigned int in_suspend;
+ unsigned longpm_misc;
+
int unit_power[20];
unsigned int pdev_id;
unsigned int irq;
@@ -169,10 +172,31 @@ x M %ld.%ld (%ld), MX1 %ld.%ld (%ld)\
fmt_freq(decode_div(pll2, pm1, 8, 112, 15, misc_div)),
fmt_freq(decode_div(pll2, pm1, 0, 14, 15, misc_div)));
}
-#else
-static void sm501_dump_clk(struct sm501_devdata *sm)
+
+static void sm501_dump_regs(struct sm501_devdata *sm)
+{
+ void __iomem *regs = sm-regs;
+
+ dev_info(sm-dev, System Control %08x\n, readl(regs +
SM501_SYSTEM_CONTROL));
+ dev_info(sm-dev, Misc Control %08x\n, readl(regs +
SM501_MISC_CONTROL));
+ dev_info(sm-dev, GPIO Control Low %08x\n, readl(regs +
SM501_GPIO31_0_CONTROL));
+ dev_info(sm-dev, GPIO Control Hi %08x\n, readl(regs +
SM501_GPIO63_32_CONTROL));
+ dev_info(sm-dev, DRAM Control %08x\n, readl(regs +
SM501_DRAM_CONTROL));
+ dev_info(sm-dev, Arbitration Ctrl %08x\n, readl(regs +
SM501_ARBTRTN_CONTROL));
+ dev_info(sm-dev, Misc Timing %08x\n, readl(regs +
SM501_MISC_TIMING));
+}
+
+static void sm501_dump_gate(struct sm501_devdata *sm)
{
+ dev_info(sm-dev, CurrentGate %08x\n, readl(sm-regs +
SM501_CURRENT_GATE));
+ dev_info(sm-dev, CurrentClock %08x\n, readl(sm-regs +
SM501_CURRENT_CLOCK));
+ dev_info(sm-dev, PowerModeControl %08x\n, readl(sm-regs +
SM501_POWER_MODE_CONTROL));
}
+
+#else
+static inline void sm501_dump_gate(struct sm501_devdata *sm) { }
+static inline void sm501_dump_regs(struct sm501_devdata *sm) { }
+static inline void sm501_dump_clk(struct sm501_devdata *sm) { }
#endif
/* sm501_sync_regs
@@ -185,9 +209,21 @@ static void sm501_sync_regs(struct sm501
readl(sm-regs);
}
+static inline void sm501_mdelay(struct sm501_devdata *sm, unsigned int delay)
+{
+ /* during suspend/resume, we are currently not allowed to sleep,
+* so change to using mdelay() instead of msleep() if we
+* are in one of these paths */
+
+ if (sm-in_suspend)
+ mdelay(delay);
+ else
+ msleep(delay);
+}
+
/* sm501_misc_control
*
- * alters the misceleneous control parameters
+ * alters the miscellaneous control parameters
*/
int sm501_misc_control(struct device *dev,
@@ -368,7 +404,7 @@ int sm501_unit_power(struct device *dev,
dev_dbg(sm-dev, gate %08lx, clock %08lx, mode %08lx\n,
gate, clock, mode);
- msleep(16);
+ sm501_mdelay(sm, 16);
already:
mutex_unlock(sm-clock_lock);
@@ -538,7 +574,7 @@ unsigned long sm501_set_clock(struct dev
dev_info(sm-dev, gate %08lx, clock %08lx, mode %08lx\n,
gate, clock, mode);
- msleep(16);
+ sm501_mdelay(sm, 16);
mutex_unlock(sm-clock_lock);
sm501_dump_clk(sm);
@@ -841,9 +877,7 @@ static int sm501_init_dev(struct sm501_d
sm-regs, readl(sm-regs + SM501_DEVICEID),
(unsigned long)mem_avail 20, sm-irq);
- dev_info(sm-dev, CurrentGate %08x\n, readl(sm-regs+0x38));
- dev_info(sm-dev, CurrentClock %08x\n, readl(sm-regs+0x3c));
- dev_info(sm-dev, PowerModeControl %08x\n, readl(sm-regs+0x54));
+ sm501_dump_gate(sm);
ret = device_create_file(sm-dev, dev_attr_dbg_regs);
if (ret)
@@ -933,6 +967,53 @@ static int sm501_plat_probe(struct platf
}
+/* power management support */
+
+static int sm501_plat_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct sm501_devdata *sm = platform_get_drvdata(pdev);
+
+ sm-in_suspend = 1;
+ sm-pm_misc = readl(sm-regs + SM501_MISC_CONTROL);
+
+ sm501_dump_regs(sm);
+ return 0;
+}
+
+static int sm501_plat_resume(struct platform_device *pdev)
+{
+ struct sm501_devdata *sm = platform_get_drvdata(pdev);
+
+ sm501_dump_regs(sm);
+ sm501_dump_gate(sm);
+ sm501_dump_clk(sm);
+
+ /* check to see if we are in the same state as when suspended */
+
+ if (readl(sm-regs + SM501_MISC_CONTROL) != sm-pm_misc) {
+ dev_info(sm-dev, SM501_MISC_CONTROL changed over sleep\n);
+ writel(sm-pm_misc, sm-regs + SM501_MISC_CONTROL);
+
+ /* our suspend causes the
Re: Runaway process and oom-killer
Chris Friesen wrote: Helge Hafting wrote: My guess: Something needs memory but finds there is none to be had oom-killer is invoked and targets myapp. myapp takes some time to die. Particularly, the memory it uses isn't freed up instantly. Has anyone considered actually bumping up the priority of the task being killed so that it gets to run and free up its resources in a timely manner? On this system, myapp runs in SCHED_RR with priority 80. IRQ handlers run in SCHED_FIFO with priority 50. # ps -eo comm,class,rtprio,ni,pri --sort -rtprio COMMAND CLS RTPRIO NI PRI posix_cpu_timer FF 99 - 139 myapp RR 80 - 120 softirq-high/0 FF 50 - 90 softirq-timer/0 FF 50 - 90 softirq-net-tx/ FF 50 - 90 softirq-net-rx/ FF 50 - 90 softirq-block/0 FF 50 - 90 softirq-tasklet FF 50 - 90 softirq-sched/0 FF 50 - 90 softirq-hrtimer FF 50 - 90 softirq-rcu/0 FF 50 - 90 IRQ-7 FF 50 - 90 IRQ-8 FF 50 - 90 IRQ-14 FF 50 - 90 IRQ-12 FF 50 - 90 IRQ-1 FF 50 - 90 IRQ-10 FF 50 - 90 IRQ-11 FF 50 - 90 IRQ-5 FF 50 - 90 IRQ-3 FF 50 - 90 IRQ-4 FF 50 - 90 events/0FF 1 - 41 initTS - 0 24 desched/0 TS - -10 34 khelper TS - -5 29 kthread TS - -5 27 kblockd/0 TS - -5 21 kacpid TS - -5 19 kseriod TS - -5 29 pdflush TS - 0 17 pdflush TS - 0 24 kswapd0 TS - -5 23 flush_filesd/0 TS - -5 29 aio/0 TS - -5 22 syslogd TS - 0 21 klogd TS - 0 21 sshdTS - 0 21 acpid TS - 0 16 agetty TS - 0 24 agetty TS - 0 21 agetty TS - 0 21 agetty TS - 0 21 [...] How do the scheduling class and priority of the process come into play when the kernel comes to reclaim memory after the oom-killer has decided to snipe that particular process? We've done some experimenting with actually putting it in SCHED_RR and it seems to help (in the case of other busy SCHED_RR tasks on the system). Admittedly we have an older kernel, so behaviour may be different now. Thanks for sharing your experience. Regards. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 on flash memory
*This message was transferred with a trial version of CommuniGate(r) Pro* Juergen Beisert wrote: So it makes no sense to find the best filesystem for such a case. There is no best one. It does make sense. Wear leveling isn't the only thing that matters. An important criteria is the total amount of wear that you get when using a filesystem. Some filesystems are simply not suitable: they either write too often to disk (though, as I said, this can be alleviated by COW-ing it or working on a copy and then updating the flash drive), or a single operation requires too many changes to its image/structure. Normal fs-s often change their internal structure, trading for space efficiency or speed. Better storage and accounting of data involve more complicated internal fs structures, that aren't too stable over time (that is, they change often and much). For example, an ISO9660 multisession rewritable CD/DVD trades space efficiency and flexibility for a lower wear and better wear-leveling. This is obvious, as the user triggers flushes to disk (that is, burning a new session) with a lower frequency, when his work is done, and the writes are always done sequentially (= wear leveling). I'm not saying anything about UDF, since I don't know much about it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
I've been following this discussion and I find this interesting. Consider these two cases: 1.) I ship the device back to the manufacturer, they replace the ROM, and ship it back to me. 2.) I ship the device back to the manufacturer, they load new code into it, and ship it back to me. How do these two differ? Or is it now just a question of the ROM Thats one thing I don't like about the GPL3 special casing. being in a socket? I can't see how the technicalities of how the hardware is constructed can change the legality of the software. In the replace/reflash the ROM case its about access to the righ tools - I could do it myself, send it to another company to load my code etc. In the Tivo case its about one company having the ability to make such mods and blocking others from doing so. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 on flash memory
*This message was transferred with a trial version of CommuniGate(r) Pro* Juergen Beisert wrote: So it makes no sense to find the best filesystem for such a case. There is no best one. It does make sense. Wear leveling isn't the only thing that matters. An important criteria is the total amount of wear that you get when using a filesystem. Some filesystems are simply not suitable: they either write too often to disk (though, as I said, this can be alleviated by COW-ing it or working on a copy and then updating the flash drive), or a single operation requires too many changes to its image/structure. Normal fs-s often change their internal structure, trading for space efficiency or speed. Better storage and accounting of data involve more complicated internal fs structures, that aren't too stable over time (that is, they change often and much). For example, an ISO9660 multisession rewritable CD/DVD trades space efficiency and flexibility for a lower wear and better wear-leveling. This is obvious, as the user triggers flushes to disk (that is, burning a new session) with a lower frequency, when his work is done, and the writes are always done sequentially (= wear leveling). I'm not saying anything about UDF, since I don't know much about it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] struct list_node
On Sun, 10 Jun 2007 15:11:30 +1000, Rusty Russell wrote:
+/* A list node is the same as the head of the list, but it's useful to
+ * think of them as a separate type. */
+struct list_node {
+ struct list_head h;
+};
+
+/* This allows us to support old style list_head as well as list_node. */
+union list_head_or_node {
+ struct list_head *_h;
+ struct list_node *_n;
+};
+union list_head_or_node_const {
+ struct list_head *_h;
+ struct list_node *_n;
+ const struct list_head *_ch;
+ const struct list_node *_cn;
+};
+#define __lh(n) (((union list_head_or_node)(n))._h)
+#define __clh(n) (((union list_head_or_node_const)(n))._h)
+
Any reason why you don't use __attribute__ ((transparent_union)) ? I guess
this is exactly the case for which it was invented.
Cheers,
Jan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thu, 2007-06-14 at 05:05 -0400, Daniel Hazelton wrote: On Thursday 14 June 2007 04:37:55 Bernd Petrovitsch wrote: [...] covered by the GPL. Indeed, TiVO has this legal right. But then they must not use Do they? At least in .at, it is usually impossible to (legally) limit the rights of the *owner* a (tangible) thing (and if I bought it, I *am* the owner and no one else) - even if you put it in the sales contract since this is discussion about/within sales law. One usual example is you buy a car and neither the car producer nor the (re)seller can restrict the brands of the tires you may use or the brand of the fuel etc.. No argument there. However, that is not to say that you bought it, now you're free to do with it whatever you please is always what the law says (at least in the US) Of course not (and I neither stated nor implied it) - there are lots of laws which forbid killing other people etc. But the seller of the car is not in the position to forbid anything (which is not forbidden by the law), e.g. ha cannot forbid to replace the motor or similar thing. I may loose guarantee or have to cope with other consequences (if it is done badly), but that is my problem and decision. In the TiVO case there may be restrictions placed on the manufacturer for legal reasons or contractual reasons. Seeing as I'm not privy to the Frankly, I really don't care that much about legal and contractual reasons of the *manufacturer* (starting from waste disposal regulations up to tax regulations, etc.) and they are irrelevant to me anyways. At most I can have *) legal restrictions (obviously coming from the law) on the *usage* of the device or *) from a contract (obviously with the seller of the device since there is no other involved - and this contract may contain inapplicable clauses - e.g. sth. like you are not allowed hear German music with this device). And I don't have a contract with the manufacturer so there can't be any limitation by the manufacturer. contracts between TiVO and the various production and broadcasting companies I can't comment on what contracts they have. As to the legal side there are And they are pretty irrelevant anyways to everyone else. restrictions in copyright law. ACK. But copyright law (at least the equivalent in .at and very probably .de - and IMHO it is probably everywhere else similar simply because copyright/authors rights laws was actually designed and written to deal with music, literature, etc. which are intangible by nature) simply doesn't apply to hardware as such (pun intended;-). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
Hi, I did run massive_intr.c for 60 secs with increasing nproc ( 10,20,30,40,50,60) waiting for effects. Below a small table of the results 2.6.21.1-cfs-v16 nproc , usability result 10 , serious frame drops , Firefox hardly recognizes clicked links, but still usable 20 - 30, usability loss ( somehow under cfs firefox never finished user requests like displaying web pages or opening new pages , no feedback anymore, sudden changes on the desktop ) ouch! The expected load-testing result under CFS should be something like this: http://bhhdoa.org.au/pipermail/ck/2007-June/007817.html could you send me the output of /proc/sched_debug? (while say a massive_intr 20 is running?) Roughly what hardware do you have? (could you send me your lspci -v output and dmesg output?) Ingo Hi, After some serious but fun testing on my machine over hours, Ingo got CFS behave on par with SD. It was my understanding that the changes were mainly adjusting tunables rather than changing code. But that is not for me to explain. From my point of view it was impressive to see the determination INGO had, to make sure he delivers the best he can :) . And I learned a lot how to provide usable / readable test results. So thumbs up for CFS and SD . ALL IMO: The current advantage of SD over CFS is the lack of need of tuning for SD . So there is certainly room for improvement for CFS. Over the weekend I'll prepare some test cases and documentation for them to test CFS and SD more specific so that a broader public can provide the same sort of (comparable) data. The test we used only covered 1 usage case. This is certainly not enough to measure the performance of such a key component. I am looking forward to the next version of CFS and I will certainly test it toroughly. kind regards to all responsiveness junkees -- Tobias Gerschner Member of Board of Yoper Linux Ltd. NZ Knowing is not enough; we must apply. Willing is not enough; we must do. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
the new language it contains. It has taken almost 15 years for Free Software to make a dent in the market, and, IMHO, a lot of that is both Linux and the holes in GPLv2. You appear terminally confused. The purpose of the GPL as defined by its authors is not commercial success, world domination or making zillions of dollars - it is keeping the software protected by that license free in terms of liberty as measured against the set of freedoms to run/modify/etc they discuss in the licence document. The fact this is a good license for making zillions of dollars, producing good software and the like is either incidental or a logical result of the protection of freedoms depending upon which views you believe. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
able to run you modifications on the same hardware? Come on! The whole idea of software is to have it run on some HW. Why would I want to change it in the first place if I can't run it ? See the difference? Forgive my poor mastery of the english language and me letting slip this inconsistency. The first sentence you cited was a general remark IMO valid outside of this context and possibly ill placed as it was. The second sentence pertains the key msg I was trying to deliver and apparently I did a poor job in phrasing it so let me redo it: Why would I want to change the SW targetted for some HW if I can't run the changed version on said HW ? [note that for the TiVo case I possibly would not own or be able to own similar HW being able to run my modified SW; so even some HW would not be triggered either] Remember I'm discussing my understanding of the spirit of the GPL, not whether the legal part actually does give me that right enforceable in court. Here is another stmt which is valid outside of this context AFAIAC: If the GPLv2 does not legally give me the right that I think its spirit gives me then the legal phrases should be changed to achieve that. Whether or not others share my view of what the spirit of the GPL implies is completely theirs to decide and if they differ they likely won't agree on my previous stmt either. Fine with me. And this leads to another observation: IMO this thread is partly fueled by a fundamental mixing of PoVs. Some argue based on their perceived view of the spirit of the GPL and some based on the actual legal phrases in GPLv2 and GPLv3 and whether or how they reflect the perceived spirit. Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi All, They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. Regards Mark Fortescue. On Wed, 13 Jun 2007, William Lee Irwin III wrote: On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote: The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Very interesting. Any hints as to how to test or how long to wait before the illegal instructions happen? -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
