Re: [PATCH] intel-iommu: fix sg_page()
On Tue, 23 Oct 2007 07:04:27 +0200
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> > drivers/pci/intel-iommu.c: In function 'intel_unmap_sg':
> > drivers/pci/intel-iommu.c:1987: error: 'struct scatterlist' has no member
> > named 'page'
> > drivers/pci/intel-iommu.c: In function 'intel_nontranslate_map_sg':
> > drivers/pci/intel-iommu.c:2013: error: 'struct scatterlist' has no member
> > named 'page'
> > drivers/pci/intel-iommu.c:2014: error: 'struct scatterlist' has no member
> > named 'page'
> > drivers/pci/intel-iommu.c: In function 'intel_map_sg':
> > drivers/pci/intel-iommu.c:2044: error: 'struct scatterlist' has no member
> > named 'page'
> > drivers/pci/intel-iommu.c:2068: error: 'struct scatterlist' has no member
> > named 'page'
> >
> > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > ---
> > drivers/pci/intel-iommu.c | 11 +--
> > 1 files changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> > index b3d7031..0f6e528 100644
> > --- a/drivers/pci/intel-iommu.c
> > +++ b/drivers/pci/intel-iommu.c
> > @@ -1962,7 +1962,6 @@ static void intel_free_coherent(struct device *hwdev,
> > size_t size,
> > free_pages((unsigned long)vaddr, order);
> > }
> >
> > -#define SG_ENT_VIRT_ADDRESS(sg)(page_address((sg)->page) +
> > (sg)->offset)
>
> Thanks, though I preferred to just do the one-liner for the conversions.
> Funny that I missed this file - ah seems it was merged yesterday as
> well, it didn't exist in the current tree I was working against.
Yeah, the patchset has been -mm and was merged after the sg updates.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index b3d7031..a837d64 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -1962,7 +1962,7 @@ static void intel_free_coherent(struct device *hwdev,
size_t size,
free_pages((unsigned long)vaddr, order);
}
-#define SG_ENT_VIRT_ADDRESS(sg)(page_address((sg)->page) +
(sg)->offset)
+#define SG_ENT_VIRT_ADDRESS(sg)sg_virt(sg)
static void intel_unmap_sg(struct device *hwdev, struct scatterlist *sglist,
int nelems, int dir)
{
@@ -2010,7 +2010,7 @@ static int intel_nontranslate_map_sg(struct device *hddev,
struct scatterlist *sg;
for_each_sg(sglist, sg, nelems, i) {
- BUG_ON(!sg->page);
+ BUG_ON(!sg_page(sg));
sg->dma_address = virt_to_bus(SG_ENT_VIRT_ADDRESS(sg));
sg->dma_length = sg->length;
}
-
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: LSM conversion to static interface
Thomas Fricaccia wrote: > Some well-respected contributors have taken exception my amplification > of Crispin Cowan's point about the patch that closes LSM. > > Crispin Cowan <[EMAIL PROTECTED]> wrote: >> * It prevents enterprise users, and in fact anyone who isn't >> comfortable compiling their own kernel, from ever trying out any >> security module that their distro vendor of choice did not ship. > > I extended this point by observing that regulatory laws make it difficult > for enterprise customers to compile their own kernels, mentioning one > of the more invasive statutes, Sarbanes-Oxley. > > In reply, "Alan Cox" <[EMAIL PROTECTED]> writes: >> Crispin at least is providing genuine discussion points. Sarbox has >> nothing to say on "using vendor linux kernels". > > And just previously, "Greg KH" <[EMAIL PROTECTED]> had written: >> Since when does Sarbanes-Oxley decree that a company must use a >> "standard kernel"? And just exactly what defines such "standard >> kernel"? Can you point out where in that bill it requires such a >> thing? > > I was actually talking about the *effects* of regulatory law, rather > than the wording in the text of the statutes. The misunderstanding > could be partially my fault, as my exact words were > >As Sarbanes-Oxley and other regulatory laws require these >customers to use "standard kernels" > > which may not have been as unambiguously clear as I intended. > > But as long as we're here, let me elaborate on the point I tried to make. > > SOX and other laws require enterprise customers to keep specified > controls on their internal processing procedures, and keep documentation > that can be audited to prove compliance. The auditing requirements > are extensive and detailed, and certainly include the kernel of an > operating system used to process business and/or financial transactions. > > It is within this framework that enterprise customers conclude something > like (and this is vernacular, not the language within the statutes) "if > we use any kernel other than that supplied by our distributor, the > SOX auditing paperwork will be a nightmare." (I've actually heard > statements similar to this, and so believe that it is an accurate > portrayal of the perception of the effects of regulatory law. I'm not > a lawyer.) > > As I said at the beginning, I meant to amplify Crispin's observation > that enterprise customers are reluctant to compile their own kernels > with the additional observation that the complexities of regulatory > law create obstacles that are significant contributors to that reluctance. > > I'll not belabor the unfortunate non sequitur further. You can find > plenty of documentation of auditing requirements with by Googling > combinations of "Sarbanes-Oxley," "operating system integrity", etc. > This is a big-business topic of wide concern. What do technical and regulatory differences have "driver/LSM module" that is build-in and one that is modular? It seems to me silly to find difference. A kernel with a new kernel module is a new kernel. ciao cate - 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] PCI: disable MSI on more ATI NorthBridges
On Mon, 22 Oct 2007, David Miller wrote: > My suggestion is: > > 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c > > 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets >a flag in the pci_dev. > > 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this >flag from #2 is set. > > 4) Add quirk entries for drivers/net/tg3.c chips and these SATA >devices we are learning about here, as well as any others we >are aware of right now. > > 5) Remove the pci_intx() workaround code from drivers/net/tg3.c >and elsewhere. Seems right to me, and pretty straightforward, except that I don't really understand the pm-related logic in there to know how that should work and whether intx will need to be enabled somewhere in addition to not disabling it in the msi enable code. -Daniel *This .sig left intentionally blank* - 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: IB/ehca: Fix sg_page() fallout
More fallout from sg_page changes:
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no
member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no
member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no
member named 'page'
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
On Tue, Oct 23, 2007 at 07:05:12AM +0200, Jens Axboe wrote:
> On Mon, Oct 22 2007, Olof Johansson wrote:
> > More fallout from sg_page changes, found with powerpc allyesconfig:
> >
> > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function
> > 'ehca_set_pagebuf_user1':
> > drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist'
> > has no member named 'page'
> > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function
> > 'ehca_check_kpages_per_ate':
> > drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist'
> > has no member named 'page'
> > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function
> > 'ehca_set_pagebuf_user2':
> > drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist'
> > has no member named 'page'
>
> Thanks a lot Olof, applied both fixups!
I messed up the second fix. :( please replace with this.
-Olof
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c
b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index da88738..ead7230 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -1776,7 +1776,7 @@ static int ehca_set_pagebuf_user1(struct ehca_mr_pginfo
*pginfo,
list_for_each_entry_continue(
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
- pgaddr = page_to_pfn(chunk->page_list[i].page)
+ pgaddr = page_to_pfn(sg_page(>page_list[i]))
<< PAGE_SHIFT ;
*kpage = phys_to_abs(pgaddr +
(pginfo->next_hwpage *
@@ -1832,7 +1832,7 @@ static int ehca_check_kpages_per_ate(struct scatterlist
*page_list,
{
int t;
for (t = start_idx; t <= end_idx; t++) {
- u64 pgaddr = page_to_pfn(page_list[t].page) << PAGE_SHIFT;
+ u64 pgaddr = page_to_pfn(sg_page(_list[t])) << PAGE_SHIFT;
ehca_gen_dbg("chunk_page=%lx value=%016lx", pgaddr,
*(u64 *)abs_to_virt(phys_to_abs(pgaddr)));
if (pgaddr - PAGE_SIZE != *prev_pgaddr) {
@@ -1867,7 +1867,7 @@ static int ehca_set_pagebuf_user2(struct ehca_mr_pginfo
*pginfo,
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
if (nr_kpages == kpages_per_hwpage) {
- pgaddr = ( page_to_pfn(chunk->page_list[i].page)
+ pgaddr = (
page_to_pfn(sg_page(>page_list[i]))
<< PAGE_SHIFT );
*kpage = phys_to_abs(pgaddr);
if ( !(*kpage) ) {
-
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: LSM conversion to static interface
Jan Engelhardt wrote: > I do have a pseudo LSM called "multiadm" at > http://freshmeat.net/p/multiadm/ , quoting: > Policy is dead simple since it is based on UIDs. The UID ranges can be > set on module load time or during runtime (sysfs params). This LSM is > basically grants extra rights unlike most other LSMs[1], which is why > modprobe makes much more sense here. (It also does not have to do any > security labelling that would require it to be loaded at boot time > already.) But his is against LSM design (and first agreements about LSM): LSM can deny rights, but it should not give extra permissions or bypass standard unix permissions. ciao cate - 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] net: fix xfrm build - missing scatterlist.h include
From: Heiko Carstens <[EMAIL PROTECTED]> net/xfrm/xfrm_algo.c: In function 'skb_icv_walk': net/xfrm/xfrm_algo.c:555: error: implicit declaration of function 'sg_set_page' make[2]: *** [net/xfrm/xfrm_algo.o] Error 1 Cc: David Miller <[EMAIL PROTECTED]> Cc: Jens Axboe <[EMAIL PROTECTED]> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- net/xfrm/xfrm_algo.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6/net/xfrm/xfrm_algo.c === --- linux-2.6.orig/net/xfrm/xfrm_algo.c +++ linux-2.6/net/xfrm/xfrm_algo.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #if defined(CONFIG_INET_AH) || defined(CONFIG_INET_AH_MODULE) || defined(CONFIG_INET6_AH) || defined(CONFIG_INET6_AH_MODULE) #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/
[PATCH] fix ll_rw_blk.c build on s390
From: Heiko Carstens <[EMAIL PROTECTED]> CC block/ll_rw_blk.o block/ll_rw_blk.c: In function 'blk_rq_map_sg': block/ll_rw_blk.c:1357: error: implicit declaration of function 'sg_dma_len' block/ll_rw_blk.c:1357: error: lvalue required as left operand of assignment block/ll_rw_blk.c:1358: error: implicit declaration of function 'sg_dma_address' block/ll_rw_blk.c:1358: error: lvalue required as left operand of assignment make[1]: *** [block/ll_rw_blk.o] Error 1 make: *** [block] Error 2 Cc: Jens Axboe <[EMAIL PROTECTED]> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- block/ll_rw_blk.c |2 -- 1 file changed, 2 deletions(-) Index: linux-2.6/block/ll_rw_blk.c === --- linux-2.6.orig/block/ll_rw_blk.c +++ linux-2.6/block/ll_rw_blk.c @@ -1354,8 +1354,6 @@ new_segment: else sg = sg_next(sg); - sg_dma_len(sg) = 0; - sg_dma_address(sg) = 0; sg_set_page(sg, bvec->bv_page); sg->length = nbytes; sg->offset = bvec->bv_offset; - 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 warning in mm/slub.c
> "Make kmem_cache_node for SLUB on memory online to avoid panic" introduced > the following: > > mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from > incompatible pointer type > > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > > > diff --git a/mm/slub.c b/mm/slub.c > index aac1dd3..bcdb2c8 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2734,7 +2734,7 @@ static void slab_mem_offline_callback(void *arg) >* and offline_pages() function shoudn't call this >* callback. So, we must fail. >*/ > - BUG_ON(atomic_read(>nr_slabs)); > + BUG_ON(atomic_long_read(>nr_slabs)); > > s->node[offline_node] = NULL; > kmem_cache_free(kmalloc_caches, n); Oops, yes. Thanks. Acked-by: Yasunori Goto <[EMAIL PROTECTED]> -- 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: [PATCH 1/1] x86: convert-cpuinfo_x86-array-to-a-per_cpu-array fix
On 10/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > This fix corrects the problem that early_identify_cpu() sets > cpu_index to '0' (needed when called by setup_arch) after > smp_store_cpu_info() had set it to the correct value. > > Signed-off-by: Mike Travis <[EMAIL PROTECTED]> > --- > arch/x86_64/kernel/smpboot.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux.orig/arch/x86_64/kernel/smpboot.c 2007-10-12 14:28:45.0 > -0700 > +++ linux/arch/x86_64/kernel/smpboot.c 2007-10-12 14:53:42.753508152 -0700 > @@ -141,8 +141,8 @@ static void __cpuinit smp_store_cpu_info > struct cpuinfo_x86 *c = _data(id); > > *c = boot_cpu_data; > - c->cpu_index = id; > identify_cpu(c); > + c->cpu_index = id; > print_cpu_info(c); > } > why not removing assignment in early_identify_cpu? YH - 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: Query about Bio submission / Direct IO
Hi list and Boaz, On 10/22/07, Boaz Harrosh <[EMAIL PROTECTED]> wrote: > On Fri, Oct 19 2007 at 8:17 +0200, Shreyansh Jain <[EMAIL PROTECTED]> wrote: > > Hi List, > > ---8<- > > Any idea why it doesn't work (though I am expecting that this doc is 2.6 > > starting era and things might have changed a lot now). > > > > Any help would be highly appreciated. Apologies if my channel of approach is > > wrong and if this post is huge (couldn't keep it shorter than this). > > > > Shreyansh > > > > > > [PS: Is this situation something to do with request flags REQ_PC / > > REQ_BLOCK_PC?? While searching code, I found these somewhere connected to > > direct IO (bio_add_pc_page) and could find more about them] > > --8<-- > > - > > There was a related fix to a similar problem by Mike Christie, in resent > Kernels, If there is no chance for you working on newer kernels, than you > will have to back port it. > > it is: > commit bd441deaf341c524b28fd72831ebf6fef88f1c41 > Author: Mike Christie <[EMAIL PROTECTED]> > Date: Tue Mar 13 12:52:29 2007 -0500 Thanks a lot for pointing that out to me. I will have a look at that. > > [SCSI] fix write buffer length in scsi_req_map_sg() > > > look it up the git trees on kernel.org Certainly I will do that :) ... Thanks > > Boaz > Shreyansh - 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: LSM conversion to static interface
On Mon, 22 Oct 2007, Crispin Cowan wrote: Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. one reason to not be willing to rebuild the kernel is that they may rely on a module from a different third party that is shipped/tested for the specific pre-compiled kernels from the distro. David Lang - 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] radeonfb: Remove warning with CONFIG_PM=n
Remove warning from powerpc ppc64_defconfig builds:
drivers/video/aty/radeon_pm.c:30: warning: 'radeon_reinitialize_M10' declared
'static' but never defined
It's used only under CONFIG_PM, and only with CONFIG_X86 before it is
defined, so the forward declaration can be moved under the ifdef.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
index be1d57b..83ee3e7 100644
--- a/drivers/video/aty/radeon_pm.c
+++ b/drivers/video/aty/radeon_pm.c
@@ -27,8 +27,6 @@
#include "ati_ids.h"
-static void radeon_reinitialize_M10(struct radeonfb_info *rinfo);
-
/*
* Workarounds for bugs in PC laptops:
* - enable D2 sleep in some IBM Thinkpads
@@ -39,6 +37,8 @@ static void radeon_reinitialize_M10(struct radeonfb_info
*rinfo);
*/
#if defined(CONFIG_PM) && defined(CONFIG_X86)
+static void radeon_reinitialize_M10(struct radeonfb_info *rinfo);
+
struct radeon_device_id {
const char *ident; /* (arbitrary) Name */
const unsigned short subsystem_vendor; /* Subsystem Vendor ID */
-
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 02/10] [SG] Update block layer to use sg helpers
On Tue, Oct 23 2007, Heiko Carstens wrote: > On Mon, Oct 22, 2007 at 08:10:56PM +0200, Jens Axboe wrote: > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > --- > > block/ll_rw_blk.c |8 ++-- > > 1 files changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c > > index 8025d64..61c2e39 100644 > > --- a/block/ll_rw_blk.c > > +++ b/block/ll_rw_blk.c > > @@ -1354,8 +1354,9 @@ new_segment: > > else > > sg = sg_next(sg); > > > > - memset(sg, 0, sizeof(*sg)); > > - sg->page = bvec->bv_page; > > + sg_dma_len(sg) = 0; > > + sg_dma_address(sg) = 0; > > + sg_set_page(sg, bvec->bv_page); > > sg->length = nbytes; > > sg->offset = bvec->bv_offset; > > nsegs++; > > @@ -1363,6 +1364,9 @@ new_segment: > > bvprv = bvec; > > } /* segments in rq */ > > > > + if (sg) > > + __sg_mark_end(sg); > > + > > return nsegs; > > } > > Hmm this breaks s390: > > CC block/ll_rw_blk.o > block/ll_rw_blk.c: In function 'blk_rq_map_sg': > block/ll_rw_blk.c:1357: error: implicit declaration of function 'sg_dma_len' > block/ll_rw_blk.c:1357: error: lvalue required as left operand of assignment > block/ll_rw_blk.c:1358: error: implicit declaration of function > 'sg_dma_address' > block/ll_rw_blk.c:1358: error: lvalue required as left operand of assignment > make[1]: *** [block/ll_rw_blk.o] Error 1 > > Missing macros and no appropriate members in struct scatterlist since we > don't have DMA. How to fix? Just remove the two lines here, there are actually not required. -- Jens Axboe - 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: LSM conversion to static interface [revert patch]
* Arjan van de Ven ([EMAIL PROTECTED]) wrote: > On Sun, 21 Oct 2007 08:57:06 +1000 (EST) > James Morris <[EMAIL PROTECTED]> wrote: > > > On Sat, 20 Oct 2007, Jan Engelhardt wrote: > > > > > >I'd like to note that I asked people who were actually affected, > > > >and had examples of their real-world use to step forward and > > > >explain their use, and that I explicitly mentioned that this is > > > >something we can easily re-visit. > > > > > > > > > > I do have a pseudo LSM called "multiadm" at > > > http://freshmeat.net/p/multiadm/ , quoting: > > > > > > > Based on Linus' criteria, this appears to be a case for reverting the > > static LSM patch. > > I don't want to argue for or against the actual revert; however if > Linus/James/Chris > decide to do a revert, I've made a patch to do that below Thanks Arjan. I did not actually oppose making it non-modular, and thought there was sufficient time for people to complain meaningfully on that change. I also think there's not a lot of value in the modular interface, but it's very difficult to have rational discussions in this area. > (doing a full git revert is tricky since it gets mixed up with various other > cleanup > patches; even inside the original patch. I've done the relevant pieces by > hand via a > selective patch -R and compile-tested it). In addition I've made the > modularity a > Kconfig option, since it's clearly something that is contested and thus is > justified > as a user compile time choice; people who don't want this (out of paranoia or > otherwise) > can now decide to disable, while others who want to experiment or use out of > tree > LSM modules, can select the KConfig option. > > If it turns out that the above module becomes unmaintained and no longer > usable, and no > other useful cases show up, we can always garbage collect this code in the > future; it's > now low-overhead anyway for those who care, due to the KConfig option. Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. thanks, -chris - 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: LSM conversion to static interface
Greg KH wrote: > On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: > >> Security is big business, as is compliance with regulatory law. Large >> enterprise customers are NOT going to either void their system support >> contracts, or place themselves in jeopardy of failing a SOX audit. >> > I agree, that is why customers do not load other random security modules > in their kernel today, That "random" module could be a module supplied by a vendor other than the distro supplier, such as a security vendor. It could be a research prototype that the user wants to try out on their enterprise-supported kernel. It could even be an in-house developed module that a local site wants to run on his larger organization's blessed kernel. So far from "random", these modules are motivated by circumstances radically different than yours. In particular, rebuilding a kernel for you (GregKH, many LKML developers) is a casual thing to be done before breakfast, but is a scary obstacle to many others. It is an obstacle to people who are skilled at computers but deliberately *not* kernel developers (the whole world does not need to be a Linux kernel developer) and it is an obstacle to large enterprise admins who have organizational pressure to use specific, pre-built kernels. > and why they will not do so tomorrow. So, > because of that, this whole point about compliance with regulatory law > seems kind of moot :) > I think the specific stuff about regulatory compliance is tangential. SarBox and friends don't specify Linux kernel versions, they are incredibly vague and subject to interpretation. But they are part of what drive organizations to have self-imposed rules about only running blessed kernel versions. Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. > Again, LSM isn't going away at all, this is just one config option for > allowing LSM to work as a module that is changing. If a customer > demands that this feature come back, I'm sure that the big distros will > be the first to push for it. But currently, given that there are no > known external LSMs being used by customers demanding support, I don't > see what the big issue here really is. > As I said, it is a medium issue, not a big one, which is why I didn't speak out before. I am opposed to this change because I see zero benefit to it, and a lot of down-side in loss of user choice. Because that is what this does: it does not help the kernel get better. It *definitely* does not help the kernel become more secure. It mostly just removes user's choice, by making it difficult to do things that some people don't approve of. As I've said, it doesn't hurt AppArmor, because 3 major distros ship it. But it will hurt user choice and innovation, by making anything not shipped by a distro more difficult to access. There is some performance gains to be had by doing something to the LSM interface. Certainly a configuration option that statically inlines all the hooks and points them at a compiled in module would yield some performance gain, but I don't know how much. But that raises 2 questions: 1. Was *performance* really the reason this patch was proposed? Or was it because James really did want the restrictive effect of preventing people from choosing after-market modules and dynamically unloading them if they want? I believe that James was well-intentioned in trying to block these actions because he believes them to be insecure, and he's right, they are insecure. However, these actions are also very practically useful in many circumstances. I disagree with the change because an individual LSM can block both such actions if you wish, so imposing it on all LSM modules is restricting choice unnecessarily. 2. Is the performance issue that this might address really big enough to bother fixing at all? Maybe, but I don't know. Again, I'm strictly opposed to the loss of flexibility until the performance issue is documented, and then I would rather see it be a configuration option you can choose to inline your module of choice, rather than the default behavior. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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 02/10] [SG] Update block layer to use sg helpers
On Mon, Oct 22, 2007 at 08:10:56PM +0200, Jens Axboe wrote: > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > --- > block/ll_rw_blk.c |8 ++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c > index 8025d64..61c2e39 100644 > --- a/block/ll_rw_blk.c > +++ b/block/ll_rw_blk.c > @@ -1354,8 +1354,9 @@ new_segment: > else > sg = sg_next(sg); > > - memset(sg, 0, sizeof(*sg)); > - sg->page = bvec->bv_page; > + sg_dma_len(sg) = 0; > + sg_dma_address(sg) = 0; > + sg_set_page(sg, bvec->bv_page); > sg->length = nbytes; > sg->offset = bvec->bv_offset; > nsegs++; > @@ -1363,6 +1364,9 @@ new_segment: > bvprv = bvec; > } /* segments in rq */ > > + if (sg) > + __sg_mark_end(sg); > + > return nsegs; > } Hmm this breaks s390: CC block/ll_rw_blk.o block/ll_rw_blk.c: In function 'blk_rq_map_sg': block/ll_rw_blk.c:1357: error: implicit declaration of function 'sg_dma_len' block/ll_rw_blk.c:1357: error: lvalue required as left operand of assignment block/ll_rw_blk.c:1358: error: implicit declaration of function 'sg_dma_address' block/ll_rw_blk.c:1358: error: lvalue required as left operand of assignment make[1]: *** [block/ll_rw_blk.o] Error 1 Missing macros and no appropriate members in struct scatterlist since we don't have DMA. How to fix? - 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] intel-iommu: fix sg_page()
On Tue, Oct 23, 2007 at 01:59:26PM +0900, FUJITA Tomonori wrote:
> drivers/pci/intel-iommu.c: In function 'intel_unmap_sg':
> drivers/pci/intel-iommu.c:1987: error: 'struct scatterlist' has no member
> named 'page'
> drivers/pci/intel-iommu.c: In function 'intel_nontranslate_map_sg':
> drivers/pci/intel-iommu.c:2013: error: 'struct scatterlist' has no member
> named 'page'
> drivers/pci/intel-iommu.c:2014: error: 'struct scatterlist' has no member
> named 'page'
> drivers/pci/intel-iommu.c: In function 'intel_map_sg':
> drivers/pci/intel-iommu.c:2044: error: 'struct scatterlist' has no member
> named 'page'
> drivers/pci/intel-iommu.c:2068: error: 'struct scatterlist' has no member
> named 'page'
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Acked by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
> ---
> drivers/pci/intel-iommu.c | 11 +--
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> index b3d7031..0f6e528 100644
> --- a/drivers/pci/intel-iommu.c
> +++ b/drivers/pci/intel-iommu.c
> @@ -1962,7 +1962,6 @@ static void intel_free_coherent(struct device *hwdev,
> size_t size,
> free_pages((unsigned long)vaddr, order);
> }
>
> -#define SG_ENT_VIRT_ADDRESS(sg) (page_address((sg)->page) +
> (sg)->offset)
> static void intel_unmap_sg(struct device *hwdev, struct scatterlist *sglist,
> int nelems, int dir)
> {
> @@ -1984,7 +1983,7 @@ static void intel_unmap_sg(struct device *hwdev, struct
> scatterlist *sglist,
> if (!iova)
> return;
> for_each_sg(sglist, sg, nelems, i) {
> - addr = SG_ENT_VIRT_ADDRESS(sg);
> + addr = sg_virt(sg);
> size += aligned_size((u64)addr, sg->length);
> }
>
> @@ -2010,8 +2009,8 @@ static int intel_nontranslate_map_sg(struct device
> *hddev,
> struct scatterlist *sg;
>
> for_each_sg(sglist, sg, nelems, i) {
> - BUG_ON(!sg->page);
> - sg->dma_address = virt_to_bus(SG_ENT_VIRT_ADDRESS(sg));
> + BUG_ON(!sg_page(sg));
> + sg->dma_address = virt_to_bus(sg_virt(sg));
> sg->dma_length = sg->length;
> }
> return nelems;
> @@ -2041,7 +2040,7 @@ static int intel_map_sg(struct device *hwdev, struct
> scatterlist *sglist,
> return 0;
>
> for_each_sg(sglist, sg, nelems, i) {
> - addr = SG_ENT_VIRT_ADDRESS(sg);
> + addr = sg_virt(sg);
> addr = (void *)virt_to_phys(addr);
> size += aligned_size((u64)addr, sg->length);
> }
> @@ -2065,7 +2064,7 @@ static int intel_map_sg(struct device *hwdev, struct
> scatterlist *sglist,
> start_addr = iova->pfn_lo << PAGE_SHIFT_4K;
> offset = 0;
> for_each_sg(sglist, sg, nelems, i) {
> - addr = SG_ENT_VIRT_ADDRESS(sg);
> + addr = sg_virt(sg);
> addr = (void *)virt_to_phys(addr);
> size = aligned_size((u64)addr, sg->length);
> ret = domain_page_mapping(domain, start_addr + offset,
> --
> 1.5.2.4
-
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: IB/ehca: Fix sg_page() fallout
On Mon, Oct 22 2007, Olof Johansson wrote: > More fallout from sg_page changes, found with powerpc allyesconfig: > > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1': > drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has > no member named 'page' > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function > 'ehca_check_kpages_per_ate': > drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has > no member named 'page' > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2': > drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has > no member named 'page' Thanks a lot Olof, applied both fixups! -- Jens Axboe - 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] intel-iommu: fix sg_page()
On Tue, Oct 23 2007, FUJITA Tomonori wrote: > drivers/pci/intel-iommu.c: In function 'intel_unmap_sg': > drivers/pci/intel-iommu.c:1987: error: 'struct scatterlist' has no member > named 'page' > drivers/pci/intel-iommu.c: In function 'intel_nontranslate_map_sg': > drivers/pci/intel-iommu.c:2013: error: 'struct scatterlist' has no member > named 'page' > drivers/pci/intel-iommu.c:2014: error: 'struct scatterlist' has no member > named 'page' > drivers/pci/intel-iommu.c: In function 'intel_map_sg': > drivers/pci/intel-iommu.c:2044: error: 'struct scatterlist' has no member > named 'page' > drivers/pci/intel-iommu.c:2068: error: 'struct scatterlist' has no member > named 'page' > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> > --- > drivers/pci/intel-iommu.c | 11 +-- > 1 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c > index b3d7031..0f6e528 100644 > --- a/drivers/pci/intel-iommu.c > +++ b/drivers/pci/intel-iommu.c > @@ -1962,7 +1962,6 @@ static void intel_free_coherent(struct device *hwdev, > size_t size, > free_pages((unsigned long)vaddr, order); > } > > -#define SG_ENT_VIRT_ADDRESS(sg) (page_address((sg)->page) + > (sg)->offset) Thanks, though I preferred to just do the one-liner for the conversions. Funny that I missed this file - ah seems it was merged yesterday as well, it didn't exist in the current tree I was working against. -- Jens Axboe - 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 14:56:52 +1000 (EST) James Morris <[EMAIL PROTECTED]> wrote: > On Mon, 22 Oct 2007, Arjan van de Ven wrote: > > > @@ -4895,6 +4908,7 @@ static struct security_operations selinu > > .sem_semop =selinux_sem_semop, > > > > .register_security = > > selinux_register_security, > > + .unregister_security = > > selinux_unregister_security, > > .d_instantiate =selinux_d_instantiate, > > You also need to consider whether to allow capabilities to be built > as an unloadable module. If not, then we don't need this hook added > back into SELinux. Otherwise, if it is desired, you also need to > reinstate capability_exit and general modular bits for > security/capability.c. > this just allows 3d party replacements of capability like functions; there is no need/point to have the existing capability back as modular to be honest. - 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] intel-iommu: fix sg_page()
drivers/pci/intel-iommu.c: In function 'intel_unmap_sg':
drivers/pci/intel-iommu.c:1987: error: 'struct scatterlist' has no member named
'page'
drivers/pci/intel-iommu.c: In function 'intel_nontranslate_map_sg':
drivers/pci/intel-iommu.c:2013: error: 'struct scatterlist' has no member named
'page'
drivers/pci/intel-iommu.c:2014: error: 'struct scatterlist' has no member named
'page'
drivers/pci/intel-iommu.c: In function 'intel_map_sg':
drivers/pci/intel-iommu.c:2044: error: 'struct scatterlist' has no member named
'page'
drivers/pci/intel-iommu.c:2068: error: 'struct scatterlist' has no member named
'page'
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/pci/intel-iommu.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index b3d7031..0f6e528 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -1962,7 +1962,6 @@ static void intel_free_coherent(struct device *hwdev,
size_t size,
free_pages((unsigned long)vaddr, order);
}
-#define SG_ENT_VIRT_ADDRESS(sg)(page_address((sg)->page) +
(sg)->offset)
static void intel_unmap_sg(struct device *hwdev, struct scatterlist *sglist,
int nelems, int dir)
{
@@ -1984,7 +1983,7 @@ static void intel_unmap_sg(struct device *hwdev, struct
scatterlist *sglist,
if (!iova)
return;
for_each_sg(sglist, sg, nelems, i) {
- addr = SG_ENT_VIRT_ADDRESS(sg);
+ addr = sg_virt(sg);
size += aligned_size((u64)addr, sg->length);
}
@@ -2010,8 +2009,8 @@ static int intel_nontranslate_map_sg(struct device *hddev,
struct scatterlist *sg;
for_each_sg(sglist, sg, nelems, i) {
- BUG_ON(!sg->page);
- sg->dma_address = virt_to_bus(SG_ENT_VIRT_ADDRESS(sg));
+ BUG_ON(!sg_page(sg));
+ sg->dma_address = virt_to_bus(sg_virt(sg));
sg->dma_length = sg->length;
}
return nelems;
@@ -2041,7 +2040,7 @@ static int intel_map_sg(struct device *hwdev, struct
scatterlist *sglist,
return 0;
for_each_sg(sglist, sg, nelems, i) {
- addr = SG_ENT_VIRT_ADDRESS(sg);
+ addr = sg_virt(sg);
addr = (void *)virt_to_phys(addr);
size += aligned_size((u64)addr, sg->length);
}
@@ -2065,7 +2064,7 @@ static int intel_map_sg(struct device *hwdev, struct
scatterlist *sglist,
start_addr = iova->pfn_lo << PAGE_SHIFT_4K;
offset = 0;
for_each_sg(sglist, sg, nelems, i) {
- addr = SG_ENT_VIRT_ADDRESS(sg);
+ addr = sg_virt(sg);
addr = (void *)virt_to_phys(addr);
size = aligned_size((u64)addr, sg->length);
ret = domain_page_mapping(domain, start_addr + offset,
--
1.5.2.4
-
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: LSM conversion to static interface [revert patch]
On Mon, 22 Oct 2007, Arjan van de Ven wrote: > @@ -4895,6 +4908,7 @@ static struct security_operations selinu > .sem_semop =selinux_sem_semop, > > .register_security =selinux_register_security, > + .unregister_security = selinux_unregister_security, > > .d_instantiate =selinux_d_instantiate, You also need to consider whether to allow capabilities to be built as an unloadable module. If not, then we don't need this hook added back into SELinux. Otherwise, if it is desired, you also need to reinstate capability_exit and general modular bits for security/capability.c. - James -- James Morris <[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/
[M68KNOMMU]: cleanup m68knommu timer code
Reduce the function pointer mess of the m68knommu timer code.
Call direct to the local hardware's timer setup, and expose the local
common timer interrupt handler to the lower level hardware timer.
Ultimately this will save definitions of all these functions across
all the platform code to setup the function pointers (which for
any given m68knommu CPU family member can be only one set of hardware
timer functions).
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diffstat (relative to arch/m68knommu):
kernel/setup.c |9 -
kernel/time.c | 22 --
platform/5206/config.c |9 -
platform/5206e/config.c | 10 --
platform/520x/config.c |8 +---
platform/523x/config.c |8
platform/5249/config.c | 10 --
platform/5272/config.c | 10 --
platform/527x/config.c |8
platform/528x/config.c |8
platform/5307/config.c | 10 --
platform/5307/pit.c | 15 +--
platform/5307/timers.c | 19 +++
platform/532x/config.c | 10 --
platform/5407/config.c | 10 --
15 files changed, 29 insertions(+), 137 deletions(-)
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c
linux-2.6.23.timers/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c 2007-10-10 06:31:38.0
+1000
+++ linux-2.6.23.timers/arch/m68knommu/kernel/setup.c 2007-10-19
15:08:24.0 +1000
@@ -287,12 +287,3 @@ struct seq_operations cpuinfo_op = {
.show = show_cpuinfo,
};
-void arch_gettod(int *year, int *mon, int *day, int *hour,
-int *min, int *sec)
-{
- if (mach_gettod)
- mach_gettod(year, mon, day, hour, min, sec);
- else
- *year = *mon = *day = *hour = *min = *sec = 0;
-}
-
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/time.c
linux-2.6.23.timers/arch/m68knommu/kernel/time.c
--- linux-2.6.23/arch/m68knommu/kernel/time.c 2007-10-10 06:31:38.0
+1000
+++ linux-2.6.23.timers/arch/m68knommu/kernel/time.c2007-10-19
15:08:24.0 +1000
@@ -27,7 +27,6 @@
#defineTICK_SIZE (tick_nsec / 1000)
-
static inline int set_rtc_mmss(unsigned long nowtime)
{
if (mach_set_clock_mmss)
@@ -39,15 +38,11 @@ static inline int set_rtc_mmss(unsigned
* timer_interrupt() needs to keep up the real-time clock,
* as well as call the "do_timer()" routine every clocktick
*/
-static irqreturn_t timer_interrupt(int irq, void *dummy)
+irqreturn_t arch_timer_interrupt(int irq, void *dummy)
{
/* last time the cmos clock got updated */
static long last_rtc_update=0;
- /* may need to kick the hardware timer */
- if (mach_tick)
- mach_tick();
-
write_seqlock(_lock);
do_timer(1);
@@ -103,10 +98,10 @@ void time_init(void)
{
unsigned int year, mon, day, hour, min, sec;
- extern void arch_gettod(int *year, int *mon, int *day, int *hour,
- int *min, int *sec);
-
- arch_gettod(, , , , , );
+ if (mach_gettod)
+ mach_gettod(, , , , , );
+ else
+ year = mon = day = hour = min = sec = 0;
if ((year += 1900) < 1970)
year += 100;
@@ -114,7 +109,7 @@ void time_init(void)
xtime.tv_nsec = 0;
wall_to_monotonic.tv_sec = -xtime.tv_sec;
- mach_sched_init(timer_interrupt);
+ hw_timer_init();
}
/*
@@ -128,7 +123,7 @@ void do_gettimeofday(struct timeval *tv)
do {
seq = read_seqbegin_irqsave(_lock, flags);
- usec = mach_gettimeoffset ? mach_gettimeoffset() : 0;
+ usec = hw_timer_offset();
sec = xtime.tv_sec;
usec += (xtime.tv_nsec / 1000);
} while (read_seqretry_irqrestore(_lock, seq, flags));
@@ -160,8 +155,7 @@ int do_settimeofday(struct timespec *tv)
* Discover what correction gettimeofday
* would have done, and then undo it!
*/
- if (mach_gettimeoffset)
- nsec -= (mach_gettimeoffset() * 1000);
+ nsec -= (hw_timer_offset() * 1000);
wtm_sec = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
diff -Naurp linux-2.6.23/arch/m68knommu/platform/5206/config.c
linux-2.6.23.timers/arch/m68knommu/platform/5206/config.c
--- linux-2.6.23/arch/m68knommu/platform/5206/config.c 2007-10-10
06:31:38.0 +1000
+++ linux-2.6.23.timers/arch/m68knommu/platform/5206/config.c 2007-10-19
15:11:38.0 +1000
@@ -10,13 +10,10 @@
/***/
#include
-#include
#include
#include
#include
-#include
#include
-#include
#include
#include
#include
@@ -25,9 +22,6 @@
/***/
[M68KNOMMU]: fix make archclean
Remove build reference to arch/m68knommu/boot directory, it doesn't exist. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naurp linux-2.6.23/arch/m68knommu/Makefile linux-2.6.23-uc0/arch/m68knommu/Makefile --- linux-2.6.23/arch/m68knommu/Makefile2007-10-19 10:30:58.0 +1000 +++ linux-2.6.23-uc0/arch/m68knommu/Makefile2007-10-19 10:35:41.0 +1000 @@ -117,4 +118,4 @@ core-y += arch/m68knommu/kernel/ \ libs-y += arch/m68knommu/lib/ archclean: - $(Q)$(MAKE) $(clean)=arch/m68knommu/boot + - 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/
[M68KNOMMU]: new style ColdFire UART driver
A new style serial driver for the Freescale ColdFire UART to replace
the old style one currently in the tree (drivers/serial/mcfserial.c).
Currently this UART is only found in the ColdFire CPU family of parts
(thus I prefixed this patch [M68KNOMMU]).
This has been around for a long while now, tested on all available
platforms.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/drivers/serial/mcf.c
linux-2.6.23-uc0/drivers/serial/mcf.c
--- linux-2.6.23/drivers/serial/mcf.c 1970-01-01 10:00:00.0 +1000
+++ linux-2.6.23-uc0/drivers/serial/mcf.c 2007-10-19 11:23:15.0
+1000
@@ -0,0 +1,653 @@
+//
+
+/*
+ * mcf.c -- Freescale ColdFire UART driver
+ *
+ * (C) Copyright 2003-2007, Greg Ungerer <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+//
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+//
+
+/*
+ * Some boards implement the DTR/DCD lines using GPIO lines, most
+ * don't. Dummy out the access macros for those that don't. Those
+ * that do should define these macros somewhere in there board
+ * specific inlude files.
+ */
+#if !defined(mcf_getppdcd)
+#definemcf_getppdcd(p) (1)
+#endif
+#if !defined(mcf_getppdtr)
+#definemcf_getppdtr(p) (1)
+#endif
+#if !defined(mcf_setppdtr)
+#definemcf_setppdtr(p, v) do { } while (0)
+#endif
+
+//
+
+/*
+ * Local per-uart structure.
+ */
+struct mcf_uart {
+ struct uart_portport;
+ unsigned intsigs; /* Local copy of line sigs */
+ unsigned char imr;/* Local IMR mirror */
+};
+
+//
+
+static unsigned int mcf_tx_empty(struct uart_port *port)
+{
+ return (readb(port->membase + MCFUART_USR) & MCFUART_USR_TXEMPTY) ?
+ TIOCSER_TEMT : 0;
+}
+
+//
+
+static unsigned int mcf_get_mctrl(struct uart_port *port)
+{
+ struct mcf_uart *pp = (struct mcf_uart *) port;
+ unsigned long flags;
+ unsigned int sigs;
+
+ spin_lock_irqsave(>lock, flags);
+ sigs = (readb(port->membase + MCFUART_UIPR) & MCFUART_UIPR_CTS) ?
+ 0 : TIOCM_CTS;
+ sigs |= (pp->sigs & TIOCM_RTS);
+ sigs |= (mcf_getppdcd(port->line) ? TIOCM_CD : 0);
+ sigs |= (mcf_getppdtr(port->line) ? TIOCM_DTR : 0);
+ spin_unlock_irqrestore(>lock, flags);
+ return sigs;
+}
+
+//
+
+static void mcf_set_mctrl(struct uart_port *port, unsigned int sigs)
+{
+ struct mcf_uart *pp = (struct mcf_uart *) port;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ pp->sigs = sigs;
+ mcf_setppdtr(port->line, (sigs & TIOCM_DTR));
+ if (sigs & TIOCM_RTS)
+ writeb(MCFUART_UOP_RTS, port->membase + MCFUART_UOP1);
+ else
+ writeb(MCFUART_UOP_RTS, port->membase + MCFUART_UOP0);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+//
+
+static void mcf_start_tx(struct uart_port *port)
+{
+ struct mcf_uart *pp = (struct mcf_uart *) port;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ pp->imr |= MCFUART_UIR_TXREADY;
+ writeb(pp->imr, port->membase + MCFUART_UIMR);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+//
+
+static void mcf_stop_tx(struct uart_port *port)
+{
+ struct mcf_uart *pp = (struct mcf_uart *) port;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ pp->imr &= ~MCFUART_UIR_TXREADY;
+ writeb(pp->imr, port->membase + MCFUART_UIMR);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+//
+
+static void mcf_stop_rx(struct uart_port *port)
+{
+ struct mcf_uart *pp = (struct mcf_uart *) port;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ pp->imr &= ~MCFUART_UIR_RXREADY;
+ writeb(pp->imr, port->membase + MCFUART_UIMR);
+ spin_unlock_irqrestore(>lock, flags);
+}
[M68KNOMMU]: improve mii_do_cmd code in FEC driver
From: Philippe De Muyter <[EMAIL PROTECTED]>
Improve the readability of mii_do_cmd().
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/drivers/net/fec.c linux-2.6.23-uc0/drivers/net/fec.c
--- linux-2.6.23/drivers/net/fec.c 2007-10-19 10:25:49.0 +1000
+++ linux-2.6.23-uc0/drivers/net/fec.c 2007-10-19 10:34:22.0 +1000
@@ -770,14 +768,11 @@ mii_queue(struct net_device *dev, int re
static void mii_do_cmd(struct net_device *dev, const phy_cmd_t *c)
{
- int k;
-
if(!c)
return;
- for(k = 0; (c+k)->mii_data != mk_mii_end; k++) {
- mii_queue(dev, (c+k)->mii_data, (c+k)->funct);
- }
+ for (; c->mii_data != mk_mii_end; c++)
+ mii_queue(dev, c->mii_data, c->funct);
}
static void mii_parse_sr(uint mii_reg, struct net_device *dev)
-
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/
[M68KNOMMU]: remove use of undefined symbols in setup.c
Remove use of undefined symbols CONFIG_TELOS, CONFIG_M68EZ328ADS and CONFIG_ALMA_ANS. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c --- linux-2.6.23/arch/m68knommu/kernel/setup.c 2007-10-19 10:30:54.0 +1000 +++ linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c 2007-10-19 10:35:38.0 +1000 @@ -151,27 +148,15 @@ void setup_arch(char **cmdline_p) #ifdef CONFIG_ELITE printk(KERN_INFO "Modified for M5206eLITE by Rob Scott, [EMAIL PROTECTED]"); #endif -#ifdef CONFIG_TELOS - printk(KERN_INFO "Modified for Omnia ToolVox by James D. Schettine, [EMAIL PROTECTED]"); -#endif #endif printk(KERN_INFO "Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne\n"); #if defined( CONFIG_PILOT ) && defined( CONFIG_M68328 ) printk(KERN_INFO "TRG SuperPilot FLASH card support <[EMAIL PROTECTED]>\n"); #endif - #if defined( CONFIG_PILOT ) && defined( CONFIG_M68EZ328 ) printk(KERN_INFO "PalmV support by Lineo Inc. <[EMAIL PROTECTED]>\n"); #endif - -#ifdef CONFIG_M68EZ328ADS - printk(KERN_INFO "M68EZ328ADS board support (C) 1999 Vladimir Gurevich <[EMAIL PROTECTED]>\n"); -#endif - -#ifdef CONFIG_ALMA_ANS - printk(KERN_INFO "Alma Electronics board support (C) 1999 Vladimir Gurevich <[EMAIL PROTECTED]>\n"); -#endif #if defined (CONFIG_M68360) printk(KERN_INFO "QUICC port done by SED Systems <[EMAIL PROTECTED]>,\n"); printk(KERN_INFO "based on 2.0.38 port by Lineo Inc. <[EMAIL PROTECTED]>.\n"); - 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/
[M68KNOMMU]: fix syscall restart handling
Fix system call restart handling. We can call directly to the
restart handler, no need to back track through trap that isn't
even implemented on m68knommu.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/signal.c
linux-2.6.23-uc0/arch/m68knommu/kernel/signal.c
--- linux-2.6.23/arch/m68knommu/kernel/signal.c 2007-10-19 10:30:55.0
+1000
+++ linux-2.6.23-uc0/arch/m68knommu/kernel/signal.c 2007-10-19
10:35:40.0 +1000
@@ -781,15 +781,7 @@ asmlinkage int do_signal(sigset_t *oldse
/* Did we come from a system call? */
if (regs->orig_d0 >= 0) {
/* Restart the system call - no handlers present */
- if (regs->d0 == -ERESTARTNOHAND
- || regs->d0 == -ERESTARTSYS
- || regs->d0 == -ERESTARTNOINTR) {
- regs->d0 = regs->orig_d0;
- regs->pc -= 2;
- } else if (regs->d0 == -ERESTART_RESTARTBLOCK) {
- regs->d0 = __NR_restart_syscall;
- regs->pc -= 2;
- }
+ handle_restart(regs, NULL, 0);
}
return 0;
}
-
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/
[M68KNOMMU]: remove use of undefined symbol CONFIG_DISKtel
Remove use of undefined symbol CONFIG_DISKtel.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/mcfuart.h
linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h
--- linux-2.6.23/include/asm-m68knommu/mcfuart.h2007-10-19
10:21:30.0 +1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h2007-10-19
10:32:26.0 +1000
@@ -12,7 +12,6 @@
#definemcfuart_h
//
-
/*
* Define the base address of the UARTS within the MBAR address
* space.
@@ -33,7 +32,7 @@
#define MCFUART_BASE2 0x240 /* Base address of UART2 */
#define MCFUART_BASE3 0x280 /* Base address of UART3 */
#elif defined(CONFIG_M5249) || defined(CONFIG_M5307) || defined(CONFIG_M5407)
-#if defined(CONFIG_NETtel) || defined(CONFIG_DISKtel) ||
defined(CONFIG_SECUREEDGEMP3)
+#if defined(CONFIG_NETtel) || defined(CONFIG_SECUREEDGEMP3)
#define MCFUART_BASE1 0x200 /* Base address of UART1 */
#define MCFUART_BASE2 0x1c0 /* Base address of UART2 */
#else
diff -Naurp linux-2.6.23/include/asm-m68knommu/system.h
linux-2.6.23-uc0/include/asm-m68knommu/system.h
--- linux-2.6.23/include/asm-m68knommu/system.h 2007-10-19 10:21:31.0
+1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/system.h 2007-10-19
10:32:28.0 +1000
@@ -253,8 +253,7 @@ cmpxchg(volatile int *p, int old, int ne
");\
})
#elif defined(CONFIG_NETtel) || defined(CONFIG_eLIA) || \
- defined(CONFIG_DISKtel) || defined(CONFIG_SECUREEDGEMP3) || \
- defined(CONFIG_CLEOPATRA)
+ defined(CONFIG_SECUREEDGEMP3) || defined(CONFIG_CLEOPATRA)
#define HARD_RESET_NOW() ({\
asm(" \
movew #0x2700, %sr; \
-
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/
[M68KNOMMU]: add make support for Savant/Rosie1 board
From: Wilson Callan <[EMAIL PROTECTED]> Add make support for the Savant/Rosie1 board. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naurp linux-2.6.23/arch/m68knommu/Makefile linux-2.6.23-uc0/arch/m68knommu/Makefile --- linux-2.6.23/arch/m68knommu/Makefile2007-10-19 10:30:58.0 +1000 +++ linux-2.6.23-uc0/arch/m68knommu/Makefile2007-10-19 10:35:41.0 +1000 @@ -48,6 +48,7 @@ board-$(CONFIG_SNEHA) := SNEHA board-$(CONFIG_M5208EVB) := M5208EVB board-$(CONFIG_MOD5272):= MOD5272 board-$(CONFIG_AVNET) := AVNET +board-$(CONFIG_SAVANT) := SAVANT BOARD := $(board-y) model-$(CONFIG_RAMKERNEL) := ram - 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/
[M68KNOMMU]: updated defconfig
Updated defconfig with new options for m68knommu. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naurp linux-2.6.23/arch/m68knommu/defconfig linux-2.6.23-uc0/arch/m68knommu/defconfig --- linux-2.6.23/arch/m68knommu/defconfig 2007-10-19 10:30:58.0 +1000 +++ linux-2.6.23-uc0/arch/m68knommu/defconfig 2007-10-19 10:35:41.0 +1000 @@ -1,41 +1,48 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.17 -# Tue Jun 27 12:57:06 2006 +# Linux kernel version: 2.6.23 +# Thu Oct 18 13:17:38 2007 # CONFIG_M68K=y # CONFIG_MMU is not set # CONFIG_FPU is not set +CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_TIME_LOW_RES=y +CONFIG_NO_IOPORT=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # -# Code maturity level options +# General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set -# CONFIG_SYSCTL is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set -CONFIG_INITRAMFS_SOURCE="" -CONFIG_UID16=y +# CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y CONFIG_EMBEDDED=y +CONFIG_UID16=y +CONFIG_SYSCTL_SYSCALL=y # CONFIG_KALLSYMS is not set # CONFIG_HOTPLUG is not set CONFIG_PRINTK=y @@ -44,20 +51,25 @@ CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set +# CONFIG_SIGNALFD is not set +# CONFIG_EVENTFD is not set +# CONFIG_VM_EVENT_COUNTERS is not set CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set CONFIG_TINY_SHMEM=y CONFIG_BASE_SMALL=0 -# CONFIG_SLOB is not set - -# -# Loadable module support -# -# CONFIG_MODULES is not set - -# -# Block layer -# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +# CONFIG_KMOD is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set # # IO Schedulers @@ -99,6 +111,7 @@ CONFIG_CLOCK_DIV=1 # # Platform # +# CONFIG_UC5272 is not set CONFIG_M5272C3=y # CONFIG_COBRA5272 is not set # CONFIG_CANCam is not set @@ -107,7 +120,6 @@ CONFIG_M5272C3=y # CONFIG_CPU16B is not set # CONFIG_MOD5272 is not set CONFIG_FREESCALE=y -# CONFIG_LARGE_ALLOCS is not set CONFIG_4KSTACKS=y # @@ -121,6 +133,11 @@ CONFIG_RAMAUTOBIT=y # CONFIG_RAM8BIT is not set # CONFIG_RAM16BIT is not set # CONFIG_RAM32BIT is not set + +# +# ROM configuration +# +# CONFIG_ROM is not set CONFIG_RAMKERNEL=y # CONFIG_ROMKERNEL is not set CONFIG_SELECT_MEMORY_MODEL=y @@ -131,20 +148,19 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_RESOURCES_64BIT is not set +CONFIG_ZONE_DMA_FLAG=1 +CONFIG_VIRT_TO_BUS=y # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # # CONFIG_PCI is not set +# CONFIG_ARCH_SUPPORTS_MSI is not set # # PCCARD (PCMCIA/CardBus) support # -# CONFIG_PCCARD is not set - -# -# PCI Hotplug Support -# # # Executable file formats @@ -168,7 +184,6 @@ CONFIG_NET=y # # Networking options # -# CONFIG_NETDEBUG is not set CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y @@ -187,27 +202,21 @@ CONFIG_IP_FIB_HASH=y # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_DIAG is not set # CONFIG_TCP_CONG_ADVANCED is not set -CONFIG_TCP_CONG_BIC=y +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG="cubic" +# CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set +# CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set - -# -# DCCP Configuration (EXPERIMENTAL) -# # CONFIG_IP_DCCP is not set - -# -# SCTP Configuration (EXPERIMENTAL) -# # CONFIG_IP_SCTP is not set - -# -# TIPC Configuration (EXPERIMENTAL) -# # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set @@ -218,7 +227,6 @@ CONFIG_TCP_CONG_BIC=y # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set -# CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set @@ -234,7 +242,17 @@
[M68KNOMMU]: local module/elf definitions
Up to now m68knommu has been using the asm-m68k/module.h instead of
defining its own. There are recent changes there that we don't need
(fixups specifically). We don't need much support here so it makes
sense to have an m68knommu specific one now.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/module.h
linux-2.6.23-uc0/include/asm-m68knommu/module.h
--- linux-2.6.23/include/asm-m68knommu/module.h 2007-10-19 10:21:30.0
+1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/module.h 2007-10-19
10:32:26.0 +1000
@@ -1 +1,11 @@
-#include
+#ifndef ASM_M68KNOMMU_MODULE_H
+#define ASM_M68KNOMMU_MODULE_H
+
+struct mod_arch_specific {
+};
+
+#define Elf_Shdr Elf32_Shdr
+#define Elf_Sym Elf32_Sym
+#define Elf_Ehdr Elf32_Ehdr
+
+#endif /* ASM_M68KNOMMU_MODULE_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/
[M68KNOMMU]: no separate stack region to report at startup
There is no separate stack region addresses to print at startup time, so remove it from the debug listing Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c --- linux-2.6.23/arch/m68knommu/kernel/setup.c 2007-10-19 10:30:54.0 +1000 +++ linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c 2007-10-19 10:35:38.0 +1000 @@ -188,11 +173,9 @@ void setup_arch(char **cmdline_p) "BSS=0x%06x-0x%06x\n", (int) &_stext, (int) &_etext, (int) &_sdata, (int) &_edata, (int) &_sbss, (int) &_ebss); - printk(KERN_DEBUG "KERNEL -> ROMFS=0x%06x-0x%06x MEM=0x%06x-0x%06x " - "STACK=0x%06x-0x%06x\n", + printk(KERN_DEBUG "MEMORY -> ROMFS=0x%06x-0x%06x MEM=0x%06x-0x%06x\n ", (int) &_ebss, (int) memory_start, - (int) memory_start, (int) memory_end, - (int) memory_end, (int) _ramend); + (int) memory_start, (int) memory_end); #endif /* Keep a copy of command line */ - 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/
[M68KNOMMU]: add config support for Savant/Rosie1 board
From: Wilson Callan <[EMAIL PROTECTED]> Add configure support for the Savant/Rosie1 board. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naurp linux-2.6.23/arch/m68knommu/Kconfig linux-2.6.23-uc0/arch/m68knommu/Kconfig --- linux-2.6.23/arch/m68knommu/Kconfig 2007-10-19 10:30:57.0 +1000 +++ linux-2.6.23-uc0/arch/m68knommu/Kconfig 2007-10-19 10:35:41.0 +1000 @@ -451,6 +451,12 @@ config MOD5272 help Support for the Netburner MOD-5272 board. +config SAVANTrosie1 + bool "Savant Rosie1 board support" + depends on M523x + help + Support for the Savant Rosie1 board. + config ROMFS_FROM_ROM bool "ROMFS image not RAM resident" depends on (NETtel || SNAPGEAR) @@ -492,7 +498,12 @@ config SNEHA bool default y depends on CPU16B - + +config SAVANT + bool + default y + depends on SAVANTrosie1 + config AVNET bool default y - 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/
[M68KNOMMU]: improve code formating FEC driver
From: Philippe De Muyter <[EMAIL PROTECTED]>
Indent all the `else' the same way.
Remove some unecesary white space.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/drivers/net/fec.c linux-2.6.23-uc0/drivers/net/fec.c
--- linux-2.6.23/drivers/net/fec.c 2007-10-19 10:25:49.0 +1000
+++ linux-2.6.23-uc0/drivers/net/fec.c 2007-10-19 10:34:22.0 +1000
@@ -753,13 +753,11 @@ mii_queue(struct net_device *dev, int re
if (mii_head) {
mii_tail->mii_next = mip;
mii_tail = mip;
- }
- else {
+ } else {
mii_head = mii_tail = mip;
fep->hwp->fec_mii_data = regval;
}
- }
- else {
+ } else {
retval = 1;
}
@@ -794,7 +789,6 @@ static void mii_parse_sr(uint mii_reg, s
status |= PHY_STAT_FAULT;
if (mii_reg & 0x0020)
status |= PHY_STAT_ANC;
-
*s = status;
}
@@ -1241,7 +1235,6 @@ mii_link_interrupt(int irq, void * dev_i
#endif
#if defined(CONFIG_M5272)
-
/*
* Code specific to Coldfire 5272 setup.
*/
@@ -2022,8 +2015,7 @@ static void mii_relink(struct work_struc
& (PHY_STAT_100FDX | PHY_STAT_10FDX))
duplex = 1;
fec_restart(dev, duplex);
- }
- else
+ } else
fec_stop(dev);
#if 0
@@ -2121,8 +2113,7 @@ mii_discover_phy(uint mii_reg, struct ne
fep->phy_id = phytype << 16;
mii_queue(dev, mk_mii_read(MII_REG_PHYIR2),
mii_discover_phy3);
- }
- else {
+ } else {
fep->phy_addr++;
mii_queue(dev, mk_mii_read(MII_REG_PHYIR1),
mii_discover_phy);
@@ -2584,8 +2575,7 @@ fec_restart(struct net_device *dev, int
if (duplex) {
fecp->fec_r_cntrl = OPT_FRAME_SIZE | 0x04;/* MII enable */
fecp->fec_x_cntrl = 0x04; /* FD enable */
- }
- else {
+ } else {
/* MII enable|No Rcv on Xmit */
fecp->fec_r_cntrl = OPT_FRAME_SIZE | 0x06;
fecp->fec_x_cntrl = 0x00;
-
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/
[M68KNOMMU]: define __clear_user macro
From: Matt Waddel <[EMAIL PROTECTED]>
Define __clear_user macro, consistent with other architectures.
fs/signalfd.c won't compile without it.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/uaccess.h
linux-2.6.23-uc0/include/asm-m68knommu/uaccess.h
--- linux-2.6.23/include/asm-m68knommu/uaccess.h2007-10-19
10:21:31.0 +1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/uaccess.h2007-10-19
10:32:28.0 +1000
@@ -170,10 +170,12 @@ static inline long strnlen_user(const ch
*/
static inline unsigned long
-clear_user(void *to, unsigned long n)
+__clear_user(void *to, unsigned long n)
{
memset(to, 0, n);
return 0;
}
+#defineclear_user(to,n)__clear_user(to,n)
+
#endif /* _M68KNOMMU_UACCESS_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/
[M68KNOMMU]: fix syscall tracing
From: Matt Waddel <[EMAIL PROTECTED]> Fix the system call code for handling syscall tracing, so strace and gdbserver work properly. This fix originally developed by Philippe De Muyter and Stuart Hughes. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naurp linux-2.6.23/arch/m68knommu/platform/5307/entry.S linux-2.6.23-uc0/arch/m68knommu/platform/5307/entry.S --- linux-2.6.23/arch/m68knommu/platform/5307/entry.S 2007-10-19 10:30:55.0 +1000 +++ linux-2.6.23-uc0/arch/m68knommu/platform/5307/entry.S 2007-10-19 10:35:40.0 +1000 @@ -74,7 +74,8 @@ ENTRY(system_call) movel %sp,%d2 /* get thread_info pointer */ andl#-THREAD_SIZE,%d2 /* at start of kernel stack */ movel %d2,%a0 - movel %sp,%a0@(THREAD_ESP0) /* save top of frame */ + movel %a0@,%a1/* save top of frame */ + movel %sp,%a1@(TASK_THREAD+THREAD_ESP0) btst#(TIF_SYSCALL_TRACE%8),%a0@(TI_FLAGS+(31-TIF_SYSCALL_TRACE)/8) bnes1f @@ -83,6 +84,8 @@ ENTRY(system_call) movel %d0,%sp@(PT_D0) /* save the return value */ jra ret_from_exception 1: + movel #-ENOSYS,%d2/* strace needs -ENOSYS in PT_D0 */ + movel %d2,PT_D0(%sp) /* on syscall entry */ subql #4,%sp SAVE_SWITCH_STACK jbsrsyscall_trace - 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/
IB/ehca: Fix sg_page() fallout
More fallout from sg_page changes, found with powerpc allyesconfig:
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no
member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no
member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no
member named 'page'
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c
b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index da88738..a3037f3 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -1776,7 +1776,7 @@ static int ehca_set_pagebuf_user1(struct ehca_mr_pginfo
*pginfo,
list_for_each_entry_continue(
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
- pgaddr = page_to_pfn(chunk->page_list[i].page)
+ pgaddr = page_to_pfn(sg_page(chunk->page_list[i]))
<< PAGE_SHIFT ;
*kpage = phys_to_abs(pgaddr +
(pginfo->next_hwpage *
@@ -1832,7 +1832,7 @@ static int ehca_check_kpages_per_ate(struct scatterlist
*page_list,
{
int t;
for (t = start_idx; t <= end_idx; t++) {
- u64 pgaddr = page_to_pfn(page_list[t].page) << PAGE_SHIFT;
+ u64 pgaddr = page_to_pfn(sg_page(page_list[t])) << PAGE_SHIFT;
ehca_gen_dbg("chunk_page=%lx value=%016lx", pgaddr,
*(u64 *)abs_to_virt(phys_to_abs(pgaddr)));
if (pgaddr - PAGE_SIZE != *prev_pgaddr) {
@@ -1867,7 +1867,7 @@ static int ehca_set_pagebuf_user2(struct ehca_mr_pginfo
*pginfo,
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
if (nr_kpages == kpages_per_hwpage) {
- pgaddr = ( page_to_pfn(chunk->page_list[i].page)
+ pgaddr = (
page_to_pfn(sg_page(chunk->page_list[i]))
<< PAGE_SHIFT );
*kpage = phys_to_abs(pgaddr);
if ( !(*kpage) ) {
-
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] Allow sysfs_remove_group() to be called on non-added groups
It would be nice to be able to do:
for_each_thing(thing) {
error = sysfs_create_group(>kobj, attrs);
if (error) {
for_each_thing(thing)
sysfs_remove_group(>kobj, attrs);
return error;
}
}
But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes
were never added.
As discussed here ...
http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html
.. we should just return in that case instead of BUG'ing.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
fs/sysfs/group.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index f318b73..a256775 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj,
if (grp->name) {
sd = sysfs_get_dirent(dir_sd, grp->name);
- BUG_ON(!sd);
+ if (!sd)
+ return;
} else
sd = sysfs_get(dir_sd);
--
1.5.1.3.g7a33b
-
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 -v2 4/7] RT overloaded runqueues accounting
Steven wrote:
> +void cpuset_rt_set_overload(struct task_struct *tsk, int cpu)
> +{
> + cpu_set(cpu, task_cs(tsk)->rt_overload);
> +}
Question for Steven:
What locks are held when cpuset_rt_set_overload() is called?
Questions for Paul Menage:
Does 'tsk' need to be locked for the above task_cs() call?
Background concern -- one of the things that I like to think has
allowed cpusets to be useful to others is the careful documentation
of its locking requirements. I hope that the cgroup infrastructure,
and the portions of the cpuset code, such as this task_cs() call,
that were adapted to work with cgroups, have their locking needs
documented as well. I suspect that there is still some presence of
stale cpuset locking comments, and perhaps an absence of complete
comments on new cgroup locking needs. My recollection is that this
is already on your todo list -- I'm just being annoying here ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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] full suspend/resume support for i915 DRM driver
On Friday, October 19, 2007, Jesse Barnes wrote:
> Dave can you take a look at the new flag and also see what you think
> about supporting suspend/resume in the event X hasn't started yet?
> There's some #if 0'd code to support that case, but I haven't tested
> it.
Ok Dave, this one's been updated with support for suspend/resume with
or without X running (iow I removed the requirement that X initialize
the driver, which DRM drivers usually have).
Hope it looks alright, it could definitely use testing on more
machines though...
Jesse
diff --git a/linux-core/Kconfig b/linux-core/Kconfig
index 2d02c76..5e73fc7 100644
--- a/linux-core/Kconfig
+++ b/linux-core/Kconfig
@@ -50,7 +50,7 @@ config DRM_I810
choice
prompt "Intel 830M, 845G, 852GM, 855GM, 865G"
- depends on DRM && AGP && AGP_INTEL
+ depends on DRM && AGP && AGP_INTEL && !FB_INTEL
optional
config DRM_I915
@@ -60,6 +60,9 @@ config DRM_I915
852GM, 855GM, 865G, 915G, 915GM, 945G, 945GM and 965G integrated
graphics. If M is selected, the module will be called i915.
AGP support is required for this driver to work.
+
+ Note that this driver is incompatible with the Intel framebuffer
+ driver.
endchoice
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index f8ca3f4..36ce266 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -106,6 +106,7 @@ struct drm_file;
#define DRIVER_DMA_QUEUE 0x200
#define DRIVER_FB_DMA 0x400
#define DRIVER_IRQ_VBL20x800
+#define DRIVER_BIND_PCI0x1000
/[EMAIL PROTECTED]/
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index a09fa96..3d14fb4 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -340,9 +340,10 @@ int drm_init(struct drm_driver *driver,
}
}
- if (!drm_fb_loaded)
+ if (!drm_fb_loaded || (driver->driver_features & DRIVER_BIND_PCI)) {
+ printk(KERN_INFO "DRM binding to PCI device\n");
return pci_register_driver(>pci_driver);
- else {
+ } else {
for (i = 0; pciidlist[i].vendor != 0; i++) {
pid = [i];
@@ -394,7 +395,7 @@ static void drm_cleanup(struct drm_device * dev)
drm_mm_takedown(>offset_manager);
drm_ht_remove(>object_hash);
- if (!drm_fb_loaded)
+ if (!drm_fb_loaded || (dev->driver->driver_features & DRIVER_BIND_PCI))
pci_disable_device(dev->pdev);
drm_ctxbitmap_cleanup(dev);
@@ -427,7 +428,7 @@ void drm_exit(struct drm_driver *driver)
struct drm_head *head;
DRM_DEBUG("\n");
- if (drm_fb_loaded) {
+ if (drm_fb_loaded && !(driver->driver_features & DRIVER_BIND_PCI)) {
for (i = 0; i < drm_cards_limit; i++) {
head = drm_heads[i];
if (!head)
diff --git a/linux-core/drm_stub.c b/linux-core/drm_stub.c
index 07ea91e..e504865 100644
--- a/linux-core/drm_stub.c
+++ b/linux-core/drm_stub.c
@@ -230,7 +230,7 @@ int drm_get_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
if (!dev)
return -ENOMEM;
- if (!drm_fb_loaded) {
+ if (!drm_fb_loaded || (driver->driver_features & DRIVER_BIND_PCI)) {
pci_set_drvdata(pdev, dev);
ret = pci_request_regions(pdev, driver->pci_driver.name);
if (ret)
@@ -256,13 +256,13 @@ int drm_get_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
return 0;
err_g3:
- if (!drm_fb_loaded)
+ if (!drm_fb_loaded || (driver->driver_features & DRIVER_BIND_PCI))
pci_disable_device(pdev);
err_g2:
- if (!drm_fb_loaded)
+ if (!drm_fb_loaded || (driver->driver_features & DRIVER_BIND_PCI))
pci_release_regions(pdev);
err_g1:
- if (!drm_fb_loaded)
+ if (!drm_fb_loaded || (driver->driver_features & DRIVER_BIND_PCI))
pci_set_drvdata(pdev, NULL);
drm_free(dev, sizeof(*dev), DRM_MEM_STUB);
diff --git a/linux-core/i915_drv.c b/linux-core/i915_drv.c
index e337e1d..5b8b74f 100644
--- a/linux-core/i915_drv.c
+++ b/linux-core/i915_drv.c
@@ -69,6 +69,460 @@ static struct drm_bo_driver i915_bo_driver = {
};
#endif
+enum pipe {
+PIPE_A = 0,
+PIPE_B,
+};
+
+static bool i915_pipe_enabled(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (pipe == PIPE_A)
+ return (I915_READ(DPLL_A) & DPLL_VCO_ENABLE);
+ else
+ return (I915_READ(DPLL_B) & DPLL_VCO_ENABLE);
+}
+
+static void i915_save_palette(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long reg = pipe == PIPE_A ? PALETTE_A : PALETTE_B;
+ u32 *array;
+ int i;
+
+ if (!i915_pipe_enabled(dev, pipe))
+ return;
+
+ if (pipe == PIPE_A)
+
[PATCH] Fix warning in mm/slub.c
Hi, "Make kmem_cache_node for SLUB on memory online to avoid panic" introduced the following: mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from incompatible pointer type Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> diff --git a/mm/slub.c b/mm/slub.c index aac1dd3..bcdb2c8 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2734,7 +2734,7 @@ static void slab_mem_offline_callback(void *arg) * and offline_pages() function shoudn't call this * callback. So, we must fail. */ - BUG_ON(atomic_read(>nr_slabs)); + BUG_ON(atomic_long_read(>nr_slabs)); s->node[offline_node] = NULL; kmem_cache_free(kmalloc_caches, n); - 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: BUG in: Driver core: convert block from raw kobjects to core devices
On Tue, 23 Oct 2007, Kay Sievers wrote:
> There is definitely something wrong, I tried all sorts of options now,
> and a second machine, and I can never get the behavior you see. I even
> booted with init=/bin/sh.
> But true, looking at the kobject debugging for loop devices, and usb
> storage driven by the ub driver, all looks fine without the additional
> put.
Yes; I haven't been able to figure out why we get different results.
> There must be something going wrong with the block patch in conjunction
> with the crazy SCSI release logic.
I don't know -- there's nothing obviously wrong with the block patch
except the extra put_device. But you're right that the SCSI logic is
crazy. The scsi_device is the parent of the gendisk, which is the
parent of the request_queue. But the scsi_device holds a reference to
the request_queue, which is dropped in the scsi_device's release
routine! That doesn't make much sense to me, and it is complicated by
the fact that deleting a kobject doesn't drop the kobject's reference
to its parent -- only releasing the kobject does.
In fact, for my development work I normally use a patch which makes
kobjects behave better: They do drop the reference to their parent when
they are deleted. This actually is nothing more than a reversion of a
patch added several years ago to try and cover up some of the
weaknesses of the SCSI stack! Now that the SCSI stack is in better
shape, maybe my patch should be included in the mainstream kernel. The
patch is below; see what you think.
> Can you send me your .config? Just
> for a check, maybe you have some option, enabled/disabled that changes
> the behavior, and possibly brings us closer to find the bug.
I'll send it to you off-list.
Unfortunately I don't have much time to work on debugging this right
now; I'm on vacation this week.
Alan Stern
Index: usb-2.6/lib/kobject.c
===
--- usb-2.6.orig/lib/kobject.c
+++ usb-2.6/lib/kobject.c
@@ -206,12 +206,16 @@ void kobject_init(struct kobject * kobj)
static void unlink(struct kobject * kobj)
{
+ struct kobject *parent = kobj->parent;
+
if (kobj->kset) {
spin_lock(>kset->list_lock);
list_del_init(>entry);
spin_unlock(>kset->list_lock);
}
+ kobj->parent = NULL;
kobject_put(kobj);
+ kobject_put(parent);
}
/**
@@ -255,7 +259,6 @@ int kobject_add(struct kobject * kobj)
if (error) {
/* unlink does the kobject_put() for us */
unlink(kobj);
- kobject_put(parent);
/* be noisy on error issues */
if (error == -EEXIST)
@@ -498,7 +501,6 @@ void kobject_cleanup(struct kobject * ko
{
struct kobj_type * t = get_ktype(kobj);
struct kset * s = kobj->kset;
- struct kobject * parent = kobj->parent;
const char *name = kobj->k_name;
pr_debug("kobject %s: cleaning up\n",kobject_name(kobj));
@@ -515,7 +517,6 @@ void kobject_cleanup(struct kobject * ko
}
if (s)
kset_put(s);
- kobject_put(parent);
}
static void kobject_release(struct kref *kref)
-
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: LSM conversion to static interface [revert patch]
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris <[EMAIL PROTECTED]> wrote:
> On Sat, 20 Oct 2007, Jan Engelhardt wrote:
>
> > >I'd like to note that I asked people who were actually affected,
> > >and had examples of their real-world use to step forward and
> > >explain their use, and that I explicitly mentioned that this is
> > >something we can easily re-visit.
> > >
> >
> > I do have a pseudo LSM called "multiadm" at
> > http://freshmeat.net/p/multiadm/ , quoting:
> >
>
> Based on Linus' criteria, this appears to be a case for reverting the
> static LSM patch.
I don't want to argue for or against the actual revert; however if
Linus/James/Chris
decide to do a revert, I've made a patch to do that below
(doing a full git revert is tricky since it gets mixed up with various other
cleanup
patches; even inside the original patch. I've done the relevant pieces by hand
via a
selective patch -R and compile-tested it). In addition I've made the modularity
a
Kconfig option, since it's clearly something that is contested and thus is
justified
as a user compile time choice; people who don't want this (out of paranoia or
otherwise)
can now decide to disable, while others who want to experiment or use out of
tree
LSM modules, can select the KConfig option.
If it turns out that the above module becomes unmaintained and no longer
usable, and no
other useful cases show up, we can always garbage collect this code in the
future; it's
now low-overhead anyway for those who care, due to the KConfig option.
---
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: revert the modular LSM patch
Since there is a real out of tree, non-racey modular LSM module,
add back the capability to have modular LSM modules as a config option.
(note that this patch fails checkpatch.pl in a few places, however
since this is just a reverse-patch of the original code, I don't
want to fix this in order to keep exact revert behavior)
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
diff -purN linux-2.6.23-git17/include/linux.org/security.h
linux-2.6.23-git17/include/linux/security.h
--- linux-2.6.23-git17/include/linux.org/security.h 2007-10-21
10:35:49.0 +0200
+++ linux-2.6.23-git17/include/linux/security.h 2007-10-21 10:36:00.0
+0200
@@ -1178,6 +1178,10 @@ struct request_sock;
* allow module stacking.
* @name contains the name of the security module being stacked.
* @ops contains a pointer to the struct security_operations of the module
to stack.
+ * @unregister_security:
+ * remove a stacked module.
+ * @name contains the name of the security module being unstacked.
+ * @ops contains a pointer to the struct security_operations of the module
to unstack.
*
* @secid_to_secctx:
* Convert secid to security context.
@@ -1365,6 +1369,8 @@ struct security_operations {
/* allow module stacking */
int (*register_security) (const char *name,
struct security_operations *ops);
+ int (*unregister_security) (const char *name,
+ struct security_operations *ops);
void (*d_instantiate) (struct dentry *dentry, struct inode *inode);
@@ -1445,7 +1451,9 @@ struct security_operations {
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
+extern int unregister_security (struct security_operations *ops);
extern int mod_reg_security(const char *name, struct security_operations
*ops);
+extern int mod_unreg_security (const char *name, struct security_operations
*ops);
extern struct dentry *securityfs_create_file(const char *name, mode_t mode,
struct dentry *parent, void *data,
const struct file_operations
*fops);
diff -purN linux-2.6.23-git17/security.org/dummy.c
linux-2.6.23-git17/security/dummy.c
--- linux-2.6.23-git17/security.org/dummy.c 2007-10-21 02:04:21.0
+0200
+++ linux-2.6.23-git17/security/dummy.c 2007-10-21 10:36:00.0 +0200
@@ -908,6 +908,11 @@ static int dummy_register_security (cons
return -EINVAL;
}
+static int dummy_unregister_security (const char *name, struct
security_operations *ops)
+{
+ return -EINVAL;
+}
+
static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode)
{
return;
@@ -1082,6 +1087,7 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, netlink_send);
set_to_dummy_if_null(ops, netlink_recv);
set_to_dummy_if_null(ops, register_security);
+ set_to_dummy_if_null(ops, unregister_security);
set_to_dummy_if_null(ops, d_instantiate);
set_to_dummy_if_null(ops, getprocattr);
set_to_dummy_if_null(ops, setprocattr);
diff -purN linux-2.6.23-git17/security.org/Kconfig
linux-2.6.23-git17/security/Kconfig
---
powerpc: Fix fallout from sg_page() changes
Fix fallout from 18dabf473e15850c0dbc8ff13ac1e2806d542c15:
In file included from include/linux/dma-mapping.h:52,
from drivers/base/dma-mapping.c:10:
include/asm/dma-mapping.h: In function 'dma_map_sg':
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named
'page'
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named
'page'
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named
'page'
include/asm/dma-mapping.h:289: error: 'struct scatterlist' has no member named
'page'
include/asm/dma-mapping.h:290: error: 'struct scatterlist' has no member named
'page'
include/asm/dma-mapping.h: In function 'dma_sync_sg_for_cpu':
include/asm/dma-mapping.h:331: error: 'struct scatterlist' has no member named
'page'
drivers/scsi/ps3rom.c: In function 'fetch_to_dev_buffer':
drivers/scsi/ps3rom.c:150: error: 'struct scatterlist' has no member named
'page'
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/include/asm-powerpc/dma-mapping.h
b/include/asm-powerpc/dma-mapping.h
index 65be95d..ff52013 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int
nents,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg->page);
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
- sg->dma_address = page_to_bus(sg->page) + sg->offset;
+ BUG_ON(!sg_page(sg));
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
+ sg->dma_address = page_to_bus(sg_page(sg)) + sg->offset;
}
return nents;
@@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_device(struct device
*dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
index 03f19b8..17b4a7c 100644
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -147,7 +147,7 @@ static int fetch_to_dev_buffer(struct scsi_cmnd *cmd, void
*buf)
req_len = fin = 0;
scsi_for_each_sg(cmd, sgpnt, scsi_sg_count(cmd), k) {
- kaddr = kmap_atomic(sg_page(sgpnt->page), KM_IRQ0);
+ kaddr = kmap_atomic(sg_page(sgpnt), KM_IRQ0);
len = sgpnt->length;
if ((req_len + len) > buflen) {
len = buflen - req_len;
-
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: [linux-usb-devel] USB HCD: avoid duplicate local_irq_disable()
On Tue, 23 Oct 2007, Arnd Bergmann wrote:
> usb_hcd_flush_endpoint() has a retry loop that starts with a spin_lock_irq(),
> but only gives up the spinlock, not the irq_disable before jumping to the
> rescan label.
>
> Split the spin_lock_irq into the retryable part and the local_irq_disable()
> that is only done once as a micro-optimization and slight cleanup.
I agree with your sentiment, but it would be better to solve this
problem without using local_irq_disable(). The patch below does this.
---
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -1312,8 +1312,8 @@ void usb_hcd_flush_endpoint(struct usb_d
hcd = bus_to_hcd(udev->bus);
/* No more submits can occur */
-rescan:
spin_lock_irq(_urb_list_lock);
+rescan:
list_for_each_entry (urb, >urb_list, urb_list) {
int is_in;
@@ -1346,6 +1346,7 @@ rescan:
usb_put_urb (urb);
/* list contents may have changed */
+ spin_lock(_urb_list_lock);
goto rescan;
}
spin_unlock_irq(_urb_list_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: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
On Fri, 19 Oct 2007 20:40:35 +0300, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote: Hi, Vitaly, I added you on cc: for the 2.6 cleanup. Please double-check what I'm doing there and use it for your 2.4 version. I hope my intentions get clearer with an example. Now, about the specific question: > Static lock minor_table_mutex is used for minor table structure. > And dev->sem for dev manipulations and that's why for open_count. > If you will simply browse /drivers/usb dir for 2.4 you will see that > such approach is widely used there. > What's not right? The fundamental reason why you cannot lock a free-able structure with an in-structure lock is this. Imagine thread A locks in order to process a disconnect. Thread B wants to open and waits for the lock. Notice that the struct is not open, so thread A frees it. At this point, thread B is using a freed memory. The solution is to lock the instance struct dev with dev->mtx, except for the open count, which is locked by a static lock (I'm ignoring interrupts here, which cannot use mutexes). I'm sorry to say, you're quite right: a number of drivers in 2.4 got it wrong, and some (like adutux) carried it through 2.6.23. -- Pete - 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: futex strangeness in 2.6.23-mm1/UML
On Mon, Oct 22, 2007 at 09:38:12PM -0400, Rik van Riel wrote: > Wrt. the UML failures that Miklos is seeing, I imagine UML needs > to do some similar tricks. UML is just an architecture - it has no need of such tricks (although it does need to keep track of host pids, but these are in architecture data, invisible to the rest of the kernel). Jeff -- Work email - jdike at linux dot intel dot com - 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/2] irq_flags_t: intro and core annotations
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> Let me add to the chorus of voices: I continually see two cases where
> real bugs crop up:
>
> 1) hacker uses spin_lock_irq() in incorrect context (where it is not
> safe to do a blind enable/disable)
>
> 2) hacker uses spin_lock_irq() correctly, but the surrounding code
> changes, thus invalidating prior assumptions.
>
> I would even go so far as to support the drastic measure of deleting
> spin_lock_irq().
>
> spin_lock_irqsave() generates fewer bugs, is more future-proof, and by
> virtue of 'flags' permits architectures a bit more flexibility.
Could we add a debug option that warned if spin_lock_irq is
executed with IRQs turned off already?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/
USB: FIx locks and urb->status in adutux
Two main issues fixed here are:
- An improper use of in-struct lock to protect an open count
- Use of urb status for -EINPROGRESS
Also, along the way:
- Change usb_unlink_urb to usb_kill_urb. Apparently there's no need
to use usb_unlink_urb whatsoever in this driver, and the old use of
usb_kill_urb was outright racy (it unlinked and immediately freed).
- Fix indentation in adu_write. Looks like it was damaged by a script.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
If someone with a real device tested this, it would be great. Please
make sure to pull the plug while application is opening/closing.
A critical review is welcome too.
Vitaliy, this is the static lock example, which I promised on Friday.
diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index c567aa7..a8afb66 100644
--- a/drivers/usb/misc/adutux.c
+++ b/drivers/usb/misc/adutux.c
@@ -79,12 +79,22 @@ MODULE_DEVICE_TABLE(usb, device_table);
#define COMMAND_TIMEOUT(2*HZ) /* 60 second timeout for a command */
+/*
+ * The locking scheme is a vanilla 3-lock:
+ * adu_device.buflock: A spinlock, covers what IRQs touch.
+ * adutux_mutex: A Static lock to cover open_count. It would also cover
+ * any globals, but we don't have them in 2.6.
+ * adu_device.mtx: A mutex to hold across sleepers like copy_from_user.
+ * It covers all of adu_device, except the open_count
+ * and what .buflock covers.
+ */
+
/* Structure to hold all of our device specific stuff */
struct adu_device {
- struct mutexmtx; /* locks this structure */
+ struct mutexmtx;
struct usb_device* udev; /* save off the usb device pointer */
struct usb_interface* interface;
- unsigned char minor; /* the starting minor number for this
device */
+ unsigned intminor; /* the starting minor number for this
device */
charserial_number[8];
int open_count; /* number of times this port has
been opened */
@@ -107,8 +117,11 @@ struct adu_device {
char* interrupt_out_buffer;
struct usb_endpoint_descriptor* interrupt_out_endpoint;
struct urb* interrupt_out_urb;
+ int out_urb_finished;
};
+static DEFINE_MUTEX(adutux_mutex);
+
static struct usb_driver adu_driver;
static void adu_debug_data(int level, const char *function, int size,
@@ -132,29 +145,36 @@ static void adu_debug_data(int level, const char
*function, int size,
*/
static void adu_abort_transfers(struct adu_device *dev)
{
+ unsigned long flags;
+
dbg(2," %s : enter", __FUNCTION__);
- if (dev == NULL) {
- dbg(1," %s : dev is null", __FUNCTION__);
- goto exit;
- }
+ mutex_lock(>mtx);
if (dev->udev == NULL) {
dbg(1," %s : udev is null", __FUNCTION__);
goto exit;
}
- dbg(2," %s : udev state %d", __FUNCTION__, dev->udev->state);
- if (dev->udev->state == USB_STATE_NOTATTACHED) {
- dbg(1," %s : udev is not attached", __FUNCTION__);
- goto exit;
- }
-
/* shutdown transfer */
- usb_unlink_urb(dev->interrupt_in_urb);
- usb_unlink_urb(dev->interrupt_out_urb);
+
+ /* XXX Anchor these instead */
+ spin_lock_irqsave(>buflock, flags);
+ if (!dev->read_urb_finished) {
+ spin_unlock_irqrestore(>buflock, flags);
+ usb_kill_urb(dev->interrupt_in_urb);
+ } else
+ spin_unlock_irqrestore(>buflock, flags);
+
+ spin_lock_irqsave(>buflock, flags);
+ if (!dev->out_urb_finished) {
+ spin_unlock_irqrestore(>buflock, flags);
+ usb_kill_urb(dev->interrupt_out_urb);
+ } else
+ spin_unlock_irqrestore(>buflock, flags);
exit:
+ mutex_unlock(>mtx);
dbg(2," %s : leave", __FUNCTION__);
}
@@ -162,8 +182,6 @@ static void adu_delete(struct adu_device *dev)
{
dbg(2, "%s enter", __FUNCTION__);
- adu_abort_transfers(dev);
-
/* free data structures */
usb_free_urb(dev->interrupt_in_urb);
usb_free_urb(dev->interrupt_out_urb);
@@ -239,7 +257,10 @@ static void adu_interrupt_out_callback(struct urb *urb)
goto exit;
}
+ spin_lock(>buflock);
+ dev->out_urb_finished = 1;
wake_up_interruptible(>write_wait);
+ spin_unlock(>buflock);
exit:
adu_debug_data(5, __FUNCTION__, urb->actual_length,
@@ -272,13 +293,11 @@ static int adu_open(struct inode *inode, struct file
*file)
goto exit_no_device;
}
- /* lock this device */
- if ((retval = mutex_lock_interruptible(>mtx))) {
+ if ((retval = mutex_lock_interruptible(_mutex))) {
dbg(2, "%s : mutex
[PATCH -v2 3/7] push RT tasks
This patch adds an algorithm to push extra RT tasks off a run queue to
other CPU runqueues.
When more than one RT task is added to a run queue, this algorithm takes
an assertive approach to push the RT tasks that are not running onto other
run queues that have lower priority. The way this works is that the highest
RT task that is not running is looked at and we examine the runqueues on
the CPUS for that tasks affinity mask. We find the runqueue with the lowest
prio in the CPU affinity of the picked task, and if it is lower in prio than
the picked task, we push the task onto that CPU runqueue.
We continue pushing RT tasks off the current runqueue until we don't push any
more. The algorithm stops when the next highest RT task can't preempt any
other processes on other CPUS.
TODO: The algorithm may stop when there are still RT tasks that can be
migrated. Specifically, if the highest non running RT task CPU affinity
is restricted to CPUs that are running higher priority tasks, there may
be a lower priority task queued that has an affinity with a CPU that is
running a lower priority task that it could be migrated to. This
patch set does not address this issue.
Note: checkpatch reveals two over 80 character instances. I'm not sure
that breaking them up will help visually, so I left them as is.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched.c|8 +
kernel/sched_rt.c | 229 ++
2 files changed, 236 insertions(+), 1 deletion(-)
Index: linux-test.git/kernel/sched.c
===
--- linux-test.git.orig/kernel/sched.c 2007-10-22 22:31:55.0 -0400
+++ linux-test.git/kernel/sched.c 2007-10-22 22:31:59.0 -0400
@@ -1860,6 +1860,8 @@ static void finish_task_switch(struct rq
prev_state = prev->state;
finish_arch_switch(prev);
finish_lock_switch(rq, prev);
+ schedule_tail_balance_rt(rq);
+
fire_sched_in_preempt_notifiers(current);
if (mm)
mmdrop(mm);
@@ -2093,11 +2095,13 @@ static void double_rq_unlock(struct rq *
/*
* double_lock_balance - lock the busiest runqueue, this_rq is locked already.
*/
-static void double_lock_balance(struct rq *this_rq, struct rq *busiest)
+static int double_lock_balance(struct rq *this_rq, struct rq *busiest)
__releases(this_rq->lock)
__acquires(busiest->lock)
__acquires(this_rq->lock)
{
+ int ret = 0;
+
if (unlikely(!irqs_disabled())) {
/* printk() doesn't work good under rq->lock */
spin_unlock(_rq->lock);
@@ -2108,9 +2112,11 @@ static void double_lock_balance(struct r
spin_unlock(_rq->lock);
spin_lock(>lock);
spin_lock(_rq->lock);
+ ret = 1;
} else
spin_lock(>lock);
}
+ return ret;
}
/*
Index: linux-test.git/kernel/sched_rt.c
===
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-22 22:31:55.0
-0400
+++ linux-test.git/kernel/sched_rt.c2007-10-22 22:31:59.0 -0400
@@ -132,6 +132,235 @@ static void put_prev_task_rt(struct rq *
update_curr_rt(rq);
p->se.exec_start = 0;
}
+#ifdef CONFIG_SMP
+/* Only try algorithms three times */
+#define RT_MAX_TRIES 3
+
+static int double_lock_balance(struct rq *this_rq, struct rq *busiest);
+static void deactivate_task(struct rq *rq, struct task_struct *p, int sleep);
+
+/* Return the second highest RT task, NULL otherwise */
+static struct task_struct *pick_next_highest_task_rt(struct rq *rq)
+{
+ struct rt_prio_array *array = >rt.active;
+ struct task_struct *next;
+ struct list_head *queue;
+ int idx;
+
+ assert_spin_locked(>lock);
+
+ if (likely(rq->rt.rt_nr_running < 2))
+ return NULL;
+
+ idx = sched_find_first_bit(array->bitmap);
+ if (unlikely(idx >= MAX_RT_PRIO)) {
+ WARN_ON(1); /* rt_nr_running is bad */
+ return NULL;
+ }
+
+ queue = array->queue + idx;
+ next = list_entry(queue->next, struct task_struct, run_list);
+ if (unlikely(next != rq->curr))
+ return next;
+
+ if (queue->next->next != queue) {
+ /* same prio task */
+ next = list_entry(queue->next->next, struct task_struct,
run_list);
+ return next;
+ }
+
+ /* slower, but more flexible */
+ idx = find_next_bit(array->bitmap, MAX_RT_PRIO, idx+1);
+ if (unlikely(idx >= MAX_RT_PRIO)) {
+ WARN_ON(1); /* rt_nr_running was 2 and above! */
+ return NULL;
+ }
+
+ queue = array->queue + idx;
+ next = list_entry(queue->next, struct task_struct, run_list);
+
+ return next;
+}
+
+/* Will lock the
[PATCH -v2 7/7] disable CFS RT load balancing.
Since we now take an active approach to load balancing, we don't need to
balance RT tasks via CFS. In fact, this code was found to pull RT tasks
away from CPUS that the active movement performed, resulting in
large latencies.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched_rt.c | 91 +-
1 file changed, 2 insertions(+), 89 deletions(-)
Index: linux-test.git/kernel/sched_rt.c
===
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-22 22:38:04.0
-0400
+++ linux-test.git/kernel/sched_rt.c2007-10-22 22:38:33.0 -0400
@@ -576,101 +576,14 @@ static void wakeup_balance_rt(struct rq
# define wakeup_balance_rt(rq, p) do { } while (0)
#endif /* CONFIG_SMP */
-
-/*
- * Load-balancing iterator. Note: while the runqueue stays locked
- * during the whole iteration, the current task might be
- * dequeued so the iterator has to be dequeue-safe. Here we
- * achieve that by always pre-iterating before returning
- * the current task:
- */
-static struct task_struct *load_balance_start_rt(void *arg)
-{
- struct rq *rq = arg;
- struct rt_prio_array *array = >rt.active;
- struct list_head *head, *curr;
- struct task_struct *p;
- int idx;
-
- idx = sched_find_first_bit(array->bitmap);
- if (idx >= MAX_RT_PRIO)
- return NULL;
-
- head = array->queue + idx;
- curr = head->prev;
-
- p = list_entry(curr, struct task_struct, run_list);
-
- curr = curr->prev;
-
- rq->rt.rt_load_balance_idx = idx;
- rq->rt.rt_load_balance_head = head;
- rq->rt.rt_load_balance_curr = curr;
-
- return p;
-}
-
-static struct task_struct *load_balance_next_rt(void *arg)
-{
- struct rq *rq = arg;
- struct rt_prio_array *array = >rt.active;
- struct list_head *head, *curr;
- struct task_struct *p;
- int idx;
-
- idx = rq->rt.rt_load_balance_idx;
- head = rq->rt.rt_load_balance_head;
- curr = rq->rt.rt_load_balance_curr;
-
- /*
-* If we arrived back to the head again then
-* iterate to the next queue (if any):
-*/
- if (unlikely(head == curr)) {
- int next_idx = find_next_bit(array->bitmap, MAX_RT_PRIO, idx+1);
-
- if (next_idx >= MAX_RT_PRIO)
- return NULL;
-
- idx = next_idx;
- head = array->queue + idx;
- curr = head->prev;
-
- rq->rt.rt_load_balance_idx = idx;
- rq->rt.rt_load_balance_head = head;
- }
-
- p = list_entry(curr, struct task_struct, run_list);
-
- curr = curr->prev;
-
- rq->rt.rt_load_balance_curr = curr;
-
- return p;
-}
-
static unsigned long
load_balance_rt(struct rq *this_rq, int this_cpu, struct rq *busiest,
unsigned long max_nr_move, unsigned long max_load_move,
struct sched_domain *sd, enum cpu_idle_type idle,
int *all_pinned, int *this_best_prio)
{
- int nr_moved;
- struct rq_iterator rt_rq_iterator;
- unsigned long load_moved;
-
- rt_rq_iterator.start = load_balance_start_rt;
- rt_rq_iterator.next = load_balance_next_rt;
- /* pass 'busiest' rq argument into
-* load_balance_[start|next]_rt iterators
-*/
- rt_rq_iterator.arg = busiest;
-
- nr_moved = balance_tasks(this_rq, this_cpu, busiest, max_nr_move,
- max_load_move, sd, idle, all_pinned, _moved,
- this_best_prio, _rq_iterator);
-
- return load_moved;
+ /* don't touch RT tasks */
+ return 0;
}
static void task_tick_rt(struct rq *rq, struct task_struct *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/
[PATCH -v2 2/7] track highest prio queued on runqueue
This patch adds accounting to each runqueue to keep track of the
highest prio task queued on the run queue. We only care about
RT tasks, so if the run queue does not contain any active RT tasks
its priority will be considered MAX_RT_PRIO.
This information will be used for later patches.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched.c|3 +++
kernel/sched_rt.c | 18 ++
2 files changed, 21 insertions(+)
Index: linux-test.git/kernel/sched.c
===
--- linux-test.git.orig/kernel/sched.c 2007-10-22 22:31:51.0 -0400
+++ linux-test.git/kernel/sched.c 2007-10-22 22:31:55.0 -0400
@@ -267,6 +267,8 @@ struct rt_rq {
int rt_load_balance_idx;
struct list_head *rt_load_balance_head, *rt_load_balance_curr;
unsigned long rt_nr_running;
+ /* highest queued rt task prio */
+ int highest_prio;
};
/*
@@ -6725,6 +6727,7 @@ void __init sched_init(void)
rq->cpu = i;
rq->migration_thread = NULL;
INIT_LIST_HEAD(>migration_queue);
+ rq->rt.highest_prio = MAX_RT_PRIO;
#endif
atomic_set(>nr_iowait, 0);
Index: linux-test.git/kernel/sched_rt.c
===
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-22 22:31:51.0
-0400
+++ linux-test.git/kernel/sched_rt.c2007-10-22 22:31:55.0 -0400
@@ -29,6 +29,10 @@ static inline void inc_rt_tasks(struct t
{
WARN_ON(!rt_task(p));
rq->rt.rt_nr_running++;
+#ifdef CONFIG_SMP
+ if (p->prio < rq->rt.highest_prio)
+ rq->rt.highest_prio = p->prio;
+#endif /* CONFIG_SMP */
}
static inline void dec_rt_tasks(struct task_struct *p, struct rq *rq)
@@ -36,6 +40,20 @@ static inline void dec_rt_tasks(struct t
WARN_ON(!rt_task(p));
WARN_ON(!rq->rt.rt_nr_running);
rq->rt.rt_nr_running--;
+#ifdef CONFIG_SMP
+ if (rq->rt.rt_nr_running) {
+ struct rt_prio_array *array;
+
+ WARN_ON(p->prio < rq->rt.highest_prio);
+ if (p->prio == rq->rt.highest_prio) {
+ /* recalculate */
+ array = >rt.active;
+ rq->rt.highest_prio =
+ sched_find_first_bit(array->bitmap);
+ } /* otherwise leave rq->highest prio alone */
+ } else
+ rq->rt.highest_prio = MAX_RT_PRIO;
+#endif /* CONFIG_SMP */
}
static void enqueue_task_rt(struct rq *rq, struct task_struct *p, int wakeup)
--
-
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 -v2 4/7] RT overloaded runqueues accounting
This patch adds an RT overload accounting system. When a runqueue has
more than one RT task queued, it is marked as overloaded. That is that it
is a candidate to have RT tasks pulled from it.
If CONFIG_CPUSET is defined, then an rt overloaded CPU bitmask is created
in the cpusets. The algorithm for pulling tasks is limited to the cpuset
of the current task on the runqueue. Because of overlapping cpusets, it is
possible that the bitmask may get out of sync with actual overloaded RT
runqueues. But it wont cause any real harm. The worst that can happen is
that a RT task may not migrate to a CPU that it can run on when it could.
But that's a OK price to pay to keep the accounting simple and not kill
the cache on large SMP boxes.
When CONFIG_CPUSET is not set, then a single RT overload CPU mask is used.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
include/linux/cpuset.h |6
kernel/cpuset.c| 62 +
kernel/sched_rt.c | 29 ++
3 files changed, 97 insertions(+)
Index: linux-test.git/kernel/sched_rt.c
===
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-22 22:31:59.0
-0400
+++ linux-test.git/kernel/sched_rt.c2007-10-22 22:32:18.0 -0400
@@ -3,6 +3,31 @@
* policies)
*/
+#ifdef CONFIG_CPUSETS
+# define rt_overload(p) cpuset_rt_overload(p)
+# define rt_set_overload(p, cpu) cpuset_rt_set_overload(p, cpu)
+# define rt_clear_overload(p, cpu) cpuset_rt_clear_overload(p, cpu)
+# define rt_overloaded(p) cpuset_rt_overloaded(p)
+#else
+static cpumask_t rt_overload_mask;
+static inline int rt_overloaded(struct task_struct *p)
+{
+ return !cpus_empty(rt_overload_mask);
+}
+static inline cpumask_t rt_overload(struct task_struct *p)
+{
+ return rt_overload_mask;
+}
+static inline void rt_set_overload(struct task_struct *p, int cpu)
+{
+ cpu_set(cpu, rt_overload_mask);
+}
+static inline void rt_clear_overload(struct task_struct *p, int cpu)
+{
+ cpu_clear(cpu, rt_overload_mask);
+}
+#endif
+
/*
* Update the current task's runtime statistics. Skip current tasks that
* are not in our scheduling class.
@@ -32,6 +57,8 @@ static inline void inc_rt_tasks(struct t
#ifdef CONFIG_SMP
if (p->prio < rq->rt.highest_prio)
rq->rt.highest_prio = p->prio;
+ if (rq->rt.rt_nr_running > 1)
+ rt_set_overload(p, rq->cpu);
#endif /* CONFIG_SMP */
}
@@ -53,6 +80,8 @@ static inline void dec_rt_tasks(struct t
} /* otherwise leave rq->highest prio alone */
} else
rq->rt.highest_prio = MAX_RT_PRIO;
+ if (rq->rt.rt_nr_running < 2)
+ rt_clear_overload(p, rq->cpu);
#endif /* CONFIG_SMP */
}
Index: linux-test.git/include/linux/cpuset.h
===
--- linux-test.git.orig/include/linux/cpuset.h 2007-10-22 22:18:53.0
-0400
+++ linux-test.git/include/linux/cpuset.h 2007-10-22 22:32:18.0
-0400
@@ -78,6 +78,12 @@ extern void cpuset_track_online_nodes(vo
extern int current_cpuset_is_being_rebound(void);
+/* The cpuset_rt_overload code is only used when CONFIG_CPUSETS is defined */
+extern int cpuset_rt_overloaded(struct task_struct *tsk);
+extern void cpuset_rt_set_overload(struct task_struct *tsk, int cpu);
+extern cpumask_t cpuset_rt_overload(struct task_struct *tsk);
+extern void cpuset_rt_clear_overload(struct task_struct *tsk, int cpu);
+
#else /* !CONFIG_CPUSETS */
static inline int cpuset_init_early(void) { return 0; }
Index: linux-test.git/kernel/cpuset.c
===
--- linux-test.git.orig/kernel/cpuset.c 2007-10-22 22:18:53.0 -0400
+++ linux-test.git/kernel/cpuset.c 2007-10-22 22:36:29.0 -0400
@@ -84,6 +84,9 @@ struct cpuset {
cpumask_t cpus_allowed; /* CPUs allowed to tasks in cpuset */
nodemask_t mems_allowed;/* Memory Nodes allowed to tasks */
+ /* bits protected by rq locks. */
+ cpumask_t rt_overload; /* runqueue overload mask */
+
struct cpuset *parent; /* my parent */
/*
@@ -179,6 +182,7 @@ static struct cpuset top_cpuset = {
.flags = ((1 << CS_CPU_EXCLUSIVE) | (1 << CS_MEM_EXCLUSIVE)),
.cpus_allowed = CPU_MASK_ALL,
.mems_allowed = NODE_MASK_ALL,
+ .rt_overload = CPU_MASK_NONE,
};
/*
@@ -1566,6 +1570,7 @@ static void cpuset_post_clone(struct cgr
cs->mems_allowed = parent_cs->mems_allowed;
cs->cpus_allowed = parent_cs->cpus_allowed;
+ cs->rt_overload = parent_cs->rt_overload;
return;
}
@@ -1604,6 +1609,7 @@ static struct cgroup_subsys_state *cpuse
set_bit(CS_SCHED_LOAD_BALANCE, >flags);
cs->cpus_allowed = CPU_MASK_NONE;
cs->mems_allowed = NODE_MASK_NONE;
+
[PATCH -v2 6/7] wake up balance RT
This patch adds pushing of overloaded RT tasks from a runqueue that is
having tasks (most likely RT tasks) added to the run queue.
TODO: We don't cover the case of waking of new RT tasks (yet).
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched.c|2 ++
kernel/sched_rt.c | 12
2 files changed, 14 insertions(+)
Index: linux-test.git/kernel/sched_rt.c
===
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-22 22:37:28.0
-0400
+++ linux-test.git/kernel/sched_rt.c2007-10-22 22:38:04.0 -0400
@@ -559,9 +559,21 @@ static void schedule_tail_balance_rt(str
spin_unlock_irq(>lock);
}
}
+
+static void wakeup_balance_rt(struct rq *rq, struct task_struct *p)
+{
+ if (unlikely(rt_task(p)) &&
+ (p->prio >= rq->curr->prio)) {
+ /* pull_rt_task needs task to be running */
+ p->state = TASK_RUNNING;
+ push_rt_tasks(rq);
+ }
+}
+
#else /* CONFIG_SMP */
# define schedule_tail_balance_rt(rq) do { } while (0)
# define schedule_balance_rt(rq) do { } while (0)
+# define wakeup_balance_rt(rq, p) do { } while (0)
#endif /* CONFIG_SMP */
Index: linux-test.git/kernel/sched.c
===
--- linux-test.git.orig/kernel/sched.c 2007-10-22 22:37:28.0 -0400
+++ linux-test.git/kernel/sched.c 2007-10-22 22:38:04.0 -0400
@@ -22,6 +22,7 @@
* by Peter Williams
* 2007-05-06 Interactivity improvements to CFS by Mike Galbraith
* 2007-07-01 Group scheduling enhancements by Srivatsa Vaddagiri
+ * 2007-10-22 RT overload balancing by Steven Rostedt
*/
#include
@@ -1614,6 +1615,7 @@ out_activate:
update_rq_clock(rq);
activate_task(rq, p, 1);
check_preempt_curr(rq, p);
+ wakeup_balance_rt(rq, p);
success = 1;
out_running:
--
-
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 -v2 1/7] Add rt_nr_running accounting
This patch adds accounting to keep track of the number of RT tasks running
on a runqueue. This information will be used in later patches.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched.c|1 +
kernel/sched_rt.c | 17 +
2 files changed, 18 insertions(+)
Index: linux-test.git/kernel/sched.c
===
--- linux-test.git.orig/kernel/sched.c 2007-10-22 22:18:53.0 -0400
+++ linux-test.git/kernel/sched.c 2007-10-22 22:31:51.0 -0400
@@ -266,6 +266,7 @@ struct rt_rq {
struct rt_prio_array active;
int rt_load_balance_idx;
struct list_head *rt_load_balance_head, *rt_load_balance_curr;
+ unsigned long rt_nr_running;
};
/*
Index: linux-test.git/kernel/sched_rt.c
===
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-22 22:18:53.0
-0400
+++ linux-test.git/kernel/sched_rt.c2007-10-22 22:31:51.0 -0400
@@ -25,12 +25,27 @@ static void update_curr_rt(struct rq *rq
curr->se.exec_start = rq->clock;
}
+static inline void inc_rt_tasks(struct task_struct *p, struct rq *rq)
+{
+ WARN_ON(!rt_task(p));
+ rq->rt.rt_nr_running++;
+}
+
+static inline void dec_rt_tasks(struct task_struct *p, struct rq *rq)
+{
+ WARN_ON(!rt_task(p));
+ WARN_ON(!rq->rt.rt_nr_running);
+ rq->rt.rt_nr_running--;
+}
+
static void enqueue_task_rt(struct rq *rq, struct task_struct *p, int wakeup)
{
struct rt_prio_array *array = >rt.active;
list_add_tail(>run_list, array->queue + p->prio);
__set_bit(p->prio, array->bitmap);
+
+ inc_rt_tasks(p, rq);
}
/*
@@ -45,6 +60,8 @@ static void dequeue_task_rt(struct rq *r
list_del(>run_list);
if (list_empty(array->queue + p->prio))
__clear_bit(p->prio, array->bitmap);
+
+ dec_rt_tasks(p, rq);
}
/*
--
-
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 -v2 0/7] New RT Task Balancing -v2
[ Changes since V1: Updated to git tree 55b70a0300b873c0ec7ea6e33752af56f41250ce Various clean ups suggested by Gregory Haskins, Dmitry Adamushko, and Peter Zijlstra. Biggest change was recommended by Ingo Molnar. This is the use of cpusets for keeping track of RT overloaded CPUS. When CONFIG_CPUSETS is not defined, we have a single global rt_overload_mask that keeps track of the runqueues with more than one RT task queued. When CONFIG_CPUSETS is configured, that bitmask is stored in the cpusets. Note that in the case of overlapping cpusets it is possible to have inconsistent data between the bitmask and actual RT overloaded runqueues. The worst that can happen is that a task doesn't get moved quickly over to a runnable CPU. But this is a price we pay to keep from dirtying caches for large number of CPU boxes. If this does happen it gets cleaned up rather quickly since there are checks for RT overload bits being set when they shouldn't be. For most systems this is not an issue since a single cpuset is used. ] Currently in mainline the balancing of multiple RT threads is quite broken. That is to say that a high priority thread that is scheduled on a CPU with a higher priority thread, may need to unnecessarily wait while it can easily run on another CPU that's running a lower priority thread. Balancing (or migrating) tasks in general is an art. Lots of considerations must be taken into account. Cache lines, NUMA and more. This is true with general processes which expect high through put and migration can be done in batch. But when it comes to RT tasks, we really need to put them off to a CPU that they can run on as soon as possible. Even if it means a bit of cache line flushing. Right now an RT task can wait several milliseconds before it gets scheduled to run. And perhaps even longer. The migration thread is not fast enough to take care of RT tasks. To demonstrate this, I wrote a simple test. http://rostedt.homelinux.com/rt/rt-migrate-test.c (gcc -o rt-migrate-test rt-migrate-test.c -lpthread) This test expects a parameter to pass in the number of threads to create. If you add the '-c' option (check) it will terminate if the test fails one of the iterations. If you add this, pass in +1 threads. For example, on a 4 way box, I used rt-migrate-test -c 5 What this test does is to create the number of threads specified (in this case 5). Each thread is set as an RT FIFO task starting at a specified prio (default 2) and each thread being one priority higher. So with this example the 5 threads created are at priorities 2, 3, 4, 5, and 6. The parent thread sets its priority to one higher than the highest of the children (this example 7). It uses pthread_barrier_wait to synchronize the threads. Then it takes a time stamp and starts all the threads. The threads when woken up take a time stamp and compares it to the parent thread to see how long it took to be awoken. It then runs for an interval (20ms default) in a busy loop. The busy loop ends when it reaches the interval delta from the start time stamp. So if it is preempted, it may not actually run for the full interval. This is expected behavior of the test. The numbers recorded are the delta from the thread's time stamp from the parent time stamp. The number of iterations it ran the busy loop for, and the delta from a thread time stamp taken at the end of the loop to the parent time stamp. Sometimes a lower priority task might wake up before a higher priority, but this is OK, as long as the higher priority process gets the CPU when it is awoken. At the end of the test, the iteration data is printed to stdout. If a higher priority task had to wait for a lower one to finish running, then this is considered a failure. Here's an example of the output from a run against git commit 4fa4d23fa20de67df919030c1216295664866ad7. 1: 36 33 20041 39 33 len:20036 20033 40041 20039 20033 loops: 167789 167693 227167 167829 167814 On iteration 1 (starts at 0) the third task started at 20ms after the parent woke it up. We can see here that the first two tasks ran to completion before the higher priority task was even able to start. That is a 20ms latency for the higher priority task!!! So people who think that their audio would lose most latencies by upping the priority, may be in for a surprise. Since some kernel threads (like the migration thread itself) may cause this latency. To solve this issue, I've changed the RT task balancing from a passive method (migration thread) to an active method. This new method is to actively push or pull RT tasks when they are woken up or scheduled. On wake up of a task if it is an RT task, and there's already an RT task of higher priority running on its runqueue, we initiate a push_rt_tasks algorithm. This algorithm looks at the highest non-running RT task and tries to find a CPU where it can run on. It
[PATCH -v2 5/7] pull RT tasks
This patch adds the algorithm to pull tasks from RT overloaded runqueues.
When a pull RT is initiated, all overloaded runqueues are examined for
a RT task that is higher in prio than the highest prio task queued on the
target runqueue. If another runqueue holds a RT task that is of higher
prio than the highest prio task on the target runqueue is found it is pulled
to the target runqueue.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched.c|2
kernel/sched_rt.c | 196 ++
2 files changed, 187 insertions(+), 11 deletions(-)
Index: linux-test.git/kernel/sched.c
===
--- linux-test.git.orig/kernel/sched.c 2007-10-22 22:31:59.0 -0400
+++ linux-test.git/kernel/sched.c 2007-10-22 22:37:28.0 -0400
@@ -3622,6 +3622,8 @@ need_resched_nonpreemptible:
switch_count = >nvcsw;
}
+ schedule_balance_rt(rq, prev);
+
if (unlikely(!rq->nr_running))
idle_balance(cpu, rq);
Index: linux-test.git/kernel/sched_rt.c
===
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-22 22:32:18.0
-0400
+++ linux-test.git/kernel/sched_rt.c2007-10-22 22:37:28.0 -0400
@@ -168,8 +168,17 @@ static void put_prev_task_rt(struct rq *
static int double_lock_balance(struct rq *this_rq, struct rq *busiest);
static void deactivate_task(struct rq *rq, struct task_struct *p, int sleep);
+static int pick_rt_task(struct rq *rq, struct task_struct *p, int cpu)
+{
+ if (!task_running(rq, p) &&
+ (cpu < 0 || cpu_isset(cpu, p->cpus_allowed)))
+ return 1;
+ return 0;
+}
+
/* Return the second highest RT task, NULL otherwise */
-static struct task_struct *pick_next_highest_task_rt(struct rq *rq)
+static struct task_struct *pick_next_highest_task_rt(struct rq *rq,
+int cpu)
{
struct rt_prio_array *array = >rt.active;
struct task_struct *next;
@@ -188,26 +197,36 @@ static struct task_struct *pick_next_hig
}
queue = array->queue + idx;
+ BUG_ON(list_empty(queue));
+
next = list_entry(queue->next, struct task_struct, run_list);
- if (unlikely(next != rq->curr))
- return next;
+ if (unlikely(pick_rt_task(rq, next, cpu)))
+ goto out;
if (queue->next->next != queue) {
/* same prio task */
next = list_entry(queue->next->next, struct task_struct,
run_list);
- return next;
+ if (pick_rt_task(rq, next, cpu))
+ goto out;
}
+ retry:
/* slower, but more flexible */
idx = find_next_bit(array->bitmap, MAX_RT_PRIO, idx+1);
- if (unlikely(idx >= MAX_RT_PRIO)) {
- WARN_ON(1); /* rt_nr_running was 2 and above! */
+ if (unlikely(idx >= MAX_RT_PRIO))
return NULL;
- }
queue = array->queue + idx;
- next = list_entry(queue->next, struct task_struct, run_list);
+ BUG_ON(list_empty(queue));
+ list_for_each_entry(next, queue, run_list) {
+ if (pick_rt_task(rq, next, cpu))
+ goto out;
+ }
+
+ goto retry;
+
+ out:
return next;
}
@@ -296,13 +315,15 @@ static int push_rt_task(struct rq *this_
assert_spin_locked(_rq->lock);
- next_task = pick_next_highest_task_rt(this_rq);
+ next_task = pick_next_highest_task_rt(this_rq, -1);
if (!next_task)
return 0;
retry:
- if (unlikely(next_task == this_rq->curr))
+ if (unlikely(next_task == this_rq->curr)) {
+ WARN_ON(1);
return 0;
+ }
/*
* It's possible that the next_task slipped in of
@@ -326,7 +347,7 @@ static int push_rt_task(struct rq *this_
* so it is possible that next_task has changed.
* If it has, then try again.
*/
- task = pick_next_highest_task_rt(this_rq);
+ task = pick_next_highest_task_rt(this_rq, -1);
if (unlikely(task != next_task) && task && paranoid--) {
put_task_struct(next_task);
next_task = task;
@@ -371,6 +392,158 @@ static void push_rt_tasks(struct rq *rq)
;
}
+static int pull_rt_task(struct rq *this_rq)
+{
+ struct task_struct *next;
+ struct task_struct *p;
+ struct rq *src_rq;
+ cpumask_t rto_cpumask;
+ int this_cpu = this_rq->cpu;
+ int cpu;
+ int ret = 0;
+
+ assert_spin_locked(_rq->lock);
+
+ /*
+* If cpusets are used, and we have overlapping
+* run queue cpusets, then this algorithm may not catch all.
+* This is just the price you pay on
[IRQ]: Fix synchronize_irq races with IRQ handler
On Mon, Oct 22, 2007 at 07:10:05AM +1000, Benjamin Herrenschmidt wrote:
>
> Hrm... not on yet. Herbert, care to resend, looks like it fell down the
> wrong hole in Linus mailbox :-)
Thanks for the reminder Ben. Here it is again:
[IRQ]: Fix synchronize_irq races with IRQ handler
As it is some callers of synchronize_irq rely on memory barriers
to provide synchronisation against the IRQ handlers. For example,
the tg3 driver does
tp->irq_sync = 1;
smp_mb();
synchronize_irq();
and then in the IRQ handler:
if (!tp->irq_sync)
netif_rx_schedule(dev, >napi);
Unfortunately memory barriers only work well when they come in
pairs. Because we don't actually have memory barriers on the
IRQ path, the memory barrier before the synchronize_irq() doesn't
actually protect us.
In particular, synchronize_irq() may return followed by the
result of netif_rx_schedule being made visible.
This patch (mostly written by Linus) fixes this by using spin
locks instead of memory barries on the synchronize_irq() path.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 80eab7a..1f31422 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -29,12 +29,28 @@
void synchronize_irq(unsigned int irq)
{
struct irq_desc *desc = irq_desc + irq;
+ unsigned int status;
if (irq >= NR_IRQS)
return;
- while (desc->status & IRQ_INPROGRESS)
- cpu_relax();
+ do {
+ unsigned long flags;
+
+ /*
+* Wait until we're out of the critical section. This might
+* give the wrong answer due to the lack of memory barriers.
+*/
+ while (desc->status & IRQ_INPROGRESS)
+ cpu_relax();
+
+ /* Ok, that indicated we're done: double-check carefully. */
+ spin_lock_irqsave(>lock, flags);
+ status = desc->status;
+ spin_unlock_irqrestore(>lock, flags);
+
+ /* Oops, that failed? */
+ } while (status & IRQ_INPROGRESS);
}
EXPORT_SYMBOL(synchronize_irq);
-
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] Allow sysfs_remove_group() to be called on non-added groups
On Tue, Oct 23, 2007 at 12:02:39PM +1000, Michael Ellerman wrote:
> On 9/13/07, Michael Ellerman <[EMAIL PROTECTED]> wrote:
> > It would be nice to be able to do:
> >
> > for_each_thing(thing) {
> > error = sysfs_create_group(>kobj, attrs);
> > if (error) {
> > for_each_thing(thing)
> > sysfs_remove_group(>kobj, attrs);
> > return error;
> > }
> > }
> >
> > But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes
> > were never added.
> >
> > As discussed here ...
> > http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html
> >
> > .. we should just return in that case instead of BUG'ing.
> >
> > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> > ---
> > fs/sysfs/group.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> > index f318b73..a256775 100644
> > --- a/fs/sysfs/group.c
> > +++ b/fs/sysfs/group.c
> > @@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj,
> >
> > if (grp->name) {
> > sd = sysfs_get_dirent(dir_sd, grp->name);
> > - BUG_ON(!sd);
> > + if (!sd)
> > + return;
> > } else
> > sd = sysfs_get(dir_sd);
> >
> >
>
> Hi Greg,
>
> I didn't see this in your series, any objections? AFAICT it still applies.
Hm, I think I just missed it, care to forward it to me "clean" again?
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: [PATCH 2/2] CFS CGroup: Report usage
Paul Menage wrote:
> Report CPU usage in CFS Cgroup directories
>
> Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> milliseconds for that cgroup's tasks
>
> This replaces the "example CPU Accounting CGroup subsystem" that
> was merged into mainline last week.
>
> Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
>
> ---
> kernel/sched.c | 32 +++-
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> Index: container-2.6.23-mm1/kernel/sched.c
> ===
> --- container-2.6.23-mm1.orig/kernel/sched.c
> +++ container-2.6.23-mm1/kernel/sched.c
> @@ -7005,15 +7005,37 @@ static u64 cpu_shares_read_uint(struct c
> return (u64) tg->shares;
> }
>
> -static struct cftype cpu_shares = {
> -.name = "shares",
> -.read_uint = cpu_shares_read_uint,
> -.write_uint = cpu_shares_write_uint,
> +static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
> +{
> +struct task_group *tg = cgroup_tg(cgrp);
> +int i;
> +u64 res = 0;
> +for_each_possible_cpu(i) {
> +unsigned long flags;
> +spin_lock_irqsave(>cfs_rq[i]->rq->lock, flags);
> +res += tg->se[i]->sum_exec_runtime;
> +spin_unlock_irqrestore(>cfs_rq[i]->rq->lock, flags);
> +}
> +/* Convert from ns to ms */
> +do_div(res, 100);
> +return res;
> +}
> +
I think we also need the notion of load, like we have in cpu_acct.c
Don't we need to do a css_get() on the cgrp to ensure that the cgroup
does not go away if it's empty and someone does an rmdir on it?
> +static struct cftype cpu_files[] = {
> +{
> +.name = "shares",
> +.read_uint = cpu_shares_read_uint,
> +.write_uint = cpu_shares_write_uint,
> +},
> +{
> +.name = "usage",
> +.read_uint = cpu_usage_read,
> +},
> };
>
> static int cpu_cgroup_populate(struct cgroup_subsys *ss, struct cgroup
> *cont)
> {
> -return cgroup_add_file(cont, ss, _shares);
> +return cgroup_add_files(cont, ss, cpu_files, ARRAY_SIZE(cpu_files));
> }
>
> struct cgroup_subsys cpu_cgroup_subsys = {
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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: Add ACCUSYS RAID driver for Linux i386/x86-64
On Mon, Oct 22, 2007 at 07:02:53PM -0700, David Miller wrote:
> From: "Peter Chan" <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 09:45:48 +0800
>
> > Add linux-scsi and linux-kernel in mail group.
>
> Please do not post your driver as a "RAR" attachment,
> not only are most Linux folks not familiar with this
> archive format, it is also an attachment type rejected
> by just about every large email service provider out
> there.
Before resubmitting this in a different format, this looks
like it will need quite a bit of work before it's
in mergable state.
Just from a quick skim..
* Why are there separate drivers for i386 and x86-64 ?
(With i386 and x86-64 now being one arch/ this makes even
less sense)
Typically in Linux we have one driver capable of driving
the hardware, regardless of which architecture it's running on.
The differences between the two seem to be locking related,
which makes this look even more odd.
* lots of #ifdef LINUX_VERSION_CODE > 2.5.0 and similar.
These should just be removed.
* None of this should be necessary..
#include
#if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS)
#define MODVERSIONS
#endif
/* modversions.h should be before module.h */
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
#if defined(MODVERSIONS)
#include
#endif
#endif
* Don't use absolute paths in includes
#include "/usr/src/linux/drivers/scsi/scsi.h"
#include "/usr/src/linux/drivers/scsi/hosts.h"
#include "/usr/src/linux/drivers/scsi/constants.h"
#include "/usr/src/linux/drivers/scsi/sd.h"
There's no guarantee (or need) for kernel source to be there.
* Instead of reinventing a linked list implementation, use
the one from
* Use instead of reinventing your own.
* Remove pointless wrappers like..
#define iowrite32 writel
#define ioread32 readl
and just use the functions directly.
* This raises some eyebrows..
#include "/usr/src/linux/drivers/scsi/scsi_module.c"
Asides from the absolute path problem, no new drivers
should be using this file. There's even a helpful comment
inside that file telling you this.
* This isn't nice..
#define AllocRequestIndex(ResIndex)\
{\
/*DISABLE_IRQ();*/\
AllocRequest++;\
if (RequestHead == NULL) PANIC("Request FULL");\
ResIndex = RequestHead;\
ResIndex->InUsed = TRUE;\
RequestHead = RequestHead->Next;\
/*ENABLE_IRQ();*/\
}
Drivers should never panic the box unless something
seriously critical is happening. An allocation failure
doesn't sound particularly catastrophic.
* You don't need to redefine the SCSI opcodes, they are
already defined for you in
I stopped reading at this point. There's probably more lurking
under that, and scripts/checkpatch.pl will probably pick up
another bunch of nits.
Dave
--
http://www.codemonkey.org.uk
-
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: futex strangeness in 2.6.23-mm1/UML
On Mon, 2007-10-22 at 21:38 -0400, Rik van Riel wrote: > On Mon, 22 Oct 2007 21:11:43 -0400 > Rik van Riel <[EMAIL PROTECTED]> wrote: > > > I have my systems set up to automount my home directory over > > NFS when I log in. When trying to log in to the system with > > 2.6.23-mm1, I get the messages from above in my syslog, and > > the NFS filesystem is not automounted. > > > > I am thinking something in autofs or the pid-namespace* patches > > does not match up and uses a wrong PID number or process pointer > > when trying to lock things. > > > > Which code is at fault I have no idea... > > I still do not know for sure, but I have found some code that > puzzles me. > > At fork() time, task->pid is set to task->pid->numbers[0].nr > > On the other hand, fork() returns to the parent process: > > task->pid[PIDTYPE_PID]->numbers[task->pid->level].nr > > I have not unravelled the code enough yet to be sure whether > this is always the same number, but having a wrong PID number > somewhere could certainly explain these autofs4 errors: > > Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent cache > rwlock lock failed > Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error: 11 at > 65 in cache.c > > After all, autofs4 puts various kinds of PID information of the > daemon into the autofs4 waitqueue: > > fs/autofs4/waitq.c:296: > wq->uid = current->uid; > wq->gid = current->gid; > wq->pid = current->pid; > wq->tgid = current->tgid; > > Could this be related? Probably not wrt the pthreads lock fail. The value passed to the daemon are used for information purposes. The pid is used only to log who is asking for the mount. The uid and gid are used to find user name and group name and the four bits of user information are used to set values in the environment for use as macros within the map. If the values in the wait request are wrong then we probably wouldn't even know as few people will be even aware they are available. Ian - 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/
CONFIG_ACPI_PROCFS depreciated? new acpid?
Noticed that CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROC_EVENT are indicated as depreciated. Does that imply a new acpid is needed to access /sys instead? Thanks, Jeff. - 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] cifssmb.c: Wrap unused functions in appropriate #ifdef
fs/cifs/cifssmb.c - get rid of couple of unused function warnings which show up when CONFIG_CIFS_EXPERIMENTAL is not defined - wrap them in #ifdef CONFIG_CIFS_EXPERIMENTAL. Patch against current git. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6-wk/fs/cifs/cifssmb.c.orig 2007-10-21 19:12:53.0 -0400 +++ linux-2.6-wk/fs/cifs/cifssmb.c 2007-10-22 22:19:27.0 -0400 @@ -2485,7 +2485,7 @@ goto querySymLinkRetry; return rc; } - +#ifdef CONFIG_CIFS_EXPERIMENTAL /* Initialize NT TRANSACT SMB into small smb request buffer. This assumes that all NT TRANSACTS that we init here have total parm and data under about 400 bytes (to fit in small cifs @@ -2569,6 +2569,7 @@ } return 0; } +#endif int CIFSSMBQueryReparseLinkInfo(const int xid, struct cifsTconInfo *tcon, - 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/2] oProfile: oops when profile_pc() return ~0LU
This set of two patches look ok by me, but I'd like sign-offs.. Also, were they tested and found to fix the problem by Sami? Linus - 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 00/13] Use struct path in struct nameidata
On Mon, Oct 22, 2007 at 03:57:58PM +0200, Christoph Hellwig wrote: > > Any reason we've got this patchset posted by three people now? :) Two reasons actually ! - The set of patches posted by Jan last was on 2.6.23-rc8-mm1. So I thought let me help Andrew a bit by making them available on latest -mm :) And I didn't know that these were already under consideration by Andrew. - The set of patches posted by Jan didn't even pass compile test for me. So I made sure that the patches compiled and worked on x86, x86_64 and powerpc. Regards, Bharata. - 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/2] CFS CGroup: Code cleanup
On Mon, Oct 22, 2007 at 05:49:20PM -0700, Paul Menage wrote: > Clean up some CFS CGroup code > > - replace "cont" with "cgrp" in a few places in the CFS cgroup code, This change looks good to me. Thanks for doing it. > - use write_uint rather than write for cpu.shares write function Minor nit: From pov of making this patch series git bisect safe, shouldn't we be registering a write_uint() handler in this patch as well? -- Regards, vatsa - 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: [git pull] lguest: paravirt boot code
On Mon, 22 Oct 2007, Rusty Russell wrote: > > First attempt at git, so please pull carefully. I've just put the > three i386 boot changes in the repo for the moment. If this works I'll pile > on the 44 lguest patches. Well, it looked ok, but I had already merged the same patches through Andrew, so when I pulled, I had no differences. So I ended up unpulling, but not because there was anything *wrong* with your tree, just because the pull didn't give me anything but a slightly more complex history ;) Linus - 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 2/2] CFS CGroup: Report usage
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> +static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
> +{
> + struct task_group *tg = cgroup_tg(cgrp);
> + int i;
> + u64 res = 0;
> + for_each_possible_cpu(i) {
> + unsigned long flags;
> + spin_lock_irqsave(>cfs_rq[i]->rq->lock, flags);
Is the lock absolutely required here?
Hmm .. I hope the cgroup code prevents a task group from being destroyed while
we are still reading a task group's cpu usage. Is that so?
> + res += tg->se[i]->sum_exec_runtime;
> + spin_unlock_irqrestore(>cfs_rq[i]->rq->lock, flags);
> + }
> + /* Convert from ns to ms */
> + do_div(res, 100);
> + return res;
> +}
--
Regards,
vatsa
-
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 -v6 0/3] x86 boot: 32-bit boot protocol
Hi, Peter,
On Mon, 2007-10-22 at 11:42 -0700, H. Peter Anvin wrote:
> This patchset should be rebased on top of Rusty's changes; the rebase is
> fairly trivial and I was originally intending to simply commit the
> rebase as-is, with the boot protocol version bumped to 2.08.
>
> However, the documentation section is simply wrong in a number of
> places. In particular:
>
> +In 32-bit boot protocol, the first step in loading a Linux kernel
> +should still be to load the real-mode code and then examine the kernel
> +header at offset 0x01f1. But, it is not necessary to load all
> +real-mode code, just first 4K bytes traditionally known as "zero page"
> +is needed.
>
> This is incorrect. The zeropage (which really is better referred to as
> struct boot_param) should be initialized to all zero, except for the
> setup header (starting at offset 0x1f0 or 0x1f1(*)) to the length
> specified either by boot protocol version or by the byte at offset 0x201.
I will change this.
> +At entry, the CPU must be in 32-bit protected mode with paging
> +disabled; the CS and DS must be 4G flat segments; %esi holds the base
> +address of the "zero page"; %esp, %ebp, %edi should be zero.
>
> You also need to have a GDT loaded with the selectors for __BOOT_CS
> (0x10) and __BOOT_DS (0x18) containing appropriate values, and you
> should enter with interrupts disabled. For safety, set up ES and SS as
> well as DS.
>
> The bit about %esp, %ebp and %edi being zero is nonsense, although
> specifying at least %ebp == %edi == 0 for future use isn't a bad idea.
> On the other hand, %ebx *is* supposed to be zero.
I will change this.
> The documentation in zero-page.txt is wrong when it comes to protocol
> versions. Most of these fields are ancient, and only a handful of the
> remainder can be tied to specific protocol versions.
So, should the protocol of current fields be set to "ALL" as that of
setup header.
> + struct setup_data {
> + u64 next;
> + u32 type;
> + u32 len;
> + u8 data[0];
> + } __attribute__((packed));
>
> Why packed?
I will change this.
> Time permitting, I might rewrite this myself, but it may be quicker for
> you to update it.
OK, I will update it as soon as possible.
Best Regards,
Huang Ying
-
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: Sparse fix for scsi_request_fn
On Mon, 22 Oct 2007, Matthew Wilcox wrote:
>
> Introduce new __holds() macro to tell sparse it's OK to drop and then
> reacquire a lock within a function. Use it in scsi_request_fn.
Umm. This is why we write things like
static void double_lock_balance(struct rq *this_rq, struct rq *busiest)
__releases(this_rq->lock)
__acquires(busiest->lock)
__acquires(this_rq->lock)
{
...
ie your "__holds()" is nothing new, and should be written as
a pair of __releases(x) and __acquires(x), which is more readable anyway
(since it actually says what the function does!)
Linus
-
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/
[RFC] what the hell is going on with /proc/self?
What is the proc_base_stuff[] nonsense about? AFAICS, that went in with no reason whatsoever in commit 801199ce805a2412bbcd9bfe213092ec656013dd Author: Eric W. Biederman <[EMAIL PROTECTED]> Date: Mon Oct 2 02:18:48 2006 -0700 Rationale is very weak and patch adds considerable complexity for no good reason. Besides, it's obfuscated just for the hell of it: if (!IS_ERR(result) || PTR_ERR(result) != -ENOENT) instead of if (result != ERR_PTR(-ENOENT)) etc. Unless there are _real_ plans that would justify that animal, I'm going to get rid of it in the pending patch series (/proc/self cleanups, saner dentry retention for non-process parts, etc.). - 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: Add ACCUSYS RAID driver for Linux i386/x86-64
From: "Peter Chan" <[EMAIL PROTECTED]> Date: Tue, 23 Oct 2007 09:45:48 +0800 > Add linux-scsi and linux-kernel in mail group. Please do not post your driver as a "RAR" attachment, not only are most Linux folks not familiar with this archive format, it is also an attachment type rejected by just about every large email service provider out there. gmail.com itself automatically rejects this attachment type, as I just learned by seeing several hundred bounces hit vger.kernel.org's postmaster mailbox due to your posting. - 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] Allow sysfs_remove_group() to be called on non-added groups
On 9/13/07, Michael Ellerman <[EMAIL PROTECTED]> wrote:
> It would be nice to be able to do:
>
> for_each_thing(thing) {
> error = sysfs_create_group(>kobj, attrs);
> if (error) {
> for_each_thing(thing)
> sysfs_remove_group(>kobj, attrs);
> return error;
> }
> }
>
> But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes
> were never added.
>
> As discussed here ...
> http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html
>
> .. we should just return in that case instead of BUG'ing.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
> fs/sysfs/group.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index f318b73..a256775 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj,
>
> if (grp->name) {
> sd = sysfs_get_dirent(dir_sd, grp->name);
> - BUG_ON(!sd);
> + if (!sd)
> + return;
> } else
> sd = sysfs_get(dir_sd);
>
>
Hi Greg,
I didn't see this in your series, any objections? AFAICT it still applies.
cheers
-
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: Question about free/used memory on Linux
Thanks all for the answers. I could load by specifying lower amount of memory but on the newer platform(does not exist), some of the existing components will not exist while some newer ones will be added. So, it won't be entirely accurate but I could still get some idea by trying it out. Thanks, Ravi -Original Message- From: Pádraig Brady [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 3:05 AM To: Ravinandan Arakali (rarakali) Cc: Linux Kernel Subject: Re: Question about free/used memory on Linux Ravinandan Arakali (rarakali) wrote: > Hi kernel gurus, > I am trying to find out the memory that's used on my linux box. > I find that there are quite a few confusing metrics. How do I find out > the "true" used memory ? > > 1. For eg. "free -m" shows free memory (excluding buffers/caches) as > 308 MB while I can see(from "df" output) that the the tmpfs partitions > take up about 400 MB. So, does "free -m" not consider the tmpfs > partitions ? > > 2. I try to add up RSS field of all processes reported by "ps aux" > command. But is it true that this would be misleading in that, shared > memory used by, say 2 processes would show up twice here although > there's only one copy in memory. Also does this consider the fact that > there's only one copy of shared libraries ? Have a look at this script so show RAM used by programs: http://www.pixelbeat.org/scripts/ps_mem.py Note to display totals you will need this patch applied: http://lkml.org/lkml/2007/8/13/1224 Pádraig. - 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/
Sparse fix for scsi_request_fn
Introduce new __holds() macro to tell sparse it's OK to drop and then
reacquire a lock within a function. Use it in scsi_request_fn.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 207f1aa..5e0583a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1374,6 +1372,7 @@ static void scsi_softirq_done(struct request *rq)
* Lock status: IO request lock assumed to be held when called.
*/
static void scsi_request_fn(struct request_queue *q)
+ __holds(q->queue_lock)
{
struct scsi_device *sdev = q->queuedata;
struct Scsi_Host *shost;
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 86f9a3a..1611ac6 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -12,6 +12,7 @@
# define __iomem __attribute__((noderef, address_space(2)))
# define __acquires(x) __attribute__((context(x,0,1)))
# define __releases(x) __attribute__((context(x,1,0)))
+# define __holds(x)__attribute__((context(x,1,1)))
# define __acquire(x) __context__(x,1)
# define __release(x) __context__(x,-1)
# define __cond_lock(x,c) ((c) ? ({ __acquire(x); 1; }) : 0)
@@ -29,6 +30,7 @@ extern void __chk_io_ptr(const volatile void __iomem *);
# define __builtin_warning(x, y...) (1)
# define __acquires(x)
# define __releases(x)
+# define __holds(x)
# define __acquire(x) (void)0
# define __release(x) (void)0
# define __cond_lock(x,c) (c)
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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] several returns before unlocking in lmc_ioctl
I think we should keep the lmc_tracing. Use this patch instead.
--
Several returns before unlocking in lmc_ioctl
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 5ea8772..64eb578 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -142,9 +142,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
* To date internally, just copy this out to the user.
*/
case LMCIOCGINFO: /*fold01*/
-if (copy_to_user(ifr->ifr_data, >ictl, sizeof (lmc_ctl_t)))
-return -EFAULT;
-ret = 0;
+ if (copy_to_user(ifr->ifr_data, >ictl, sizeof(lmc_ctl_t)))
+ ret = -EFAULT;
+ else
+ ret = 0;
break;
case LMCIOCSINFO: /*fold01*/
@@ -159,8 +160,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
break;
}
-if (copy_from_user(, ifr->ifr_data, sizeof (lmc_ctl_t)))
-return -EFAULT;
+ if (copy_from_user(, ifr->ifr_data, sizeof(lmc_ctl_t))) {
+ ret = -EFAULT;
+ break;
+ }
sc->lmc_media->set_status (sc, );
@@ -190,8 +193,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
break;
}
- if (copy_from_user(_type, ifr->ifr_data, sizeof(u_int16_t)))
-return -EFAULT;
+ if (copy_from_user(_type, ifr->ifr_data, sizeof(u_int16_t))) {
+ ret = -EFAULT;
+ break;
+ }
if (new_type == old_type)
@@ -229,9 +234,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
sc->lmc_xinfo.Magic1 = 0xDEADBEEF;
if (copy_to_user(ifr->ifr_data, >lmc_xinfo,
- sizeof (struct lmc_xinfo)))
-return -EFAULT;
-ret = 0;
+ sizeof(struct lmc_xinfo))) {
+ ret = -EFAULT;
+ else
+ ret = 0;
break;
@@ -262,9 +268,9 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
if (copy_to_user(ifr->ifr_data, >stats,
sizeof (struct lmc_statistics)))
-return -EFAULT;
-
-ret = 0;
+ ret = -EFAULT;
+ else
+ ret = 0;
break;
case LMCIOCCLEARLMCSTATS: /*fold01*/
@@ -292,8 +298,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
break;
}
-if (copy_from_user(, ifr->ifr_data, sizeof (lmc_ctl_t)))
-return -EFAULT;
+ if (copy_from_user(, ifr->ifr_data, sizeof(lmc_ctl_t))) {
+ ret = -EFAULT;
+ break;
+ }
sc->lmc_media->set_circuit_type(sc, ctl.circuit_type);
sc->ictl.circuit_type = ctl.circuit_type;
ret = 0;
@@ -318,12 +326,15 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
#ifdef DEBUG
case LMCIOCDUMPEVENTLOG:
-if (copy_to_user(ifr->ifr_data, , sizeof (u32)))
-return -EFAULT;
+ if (copy_to_user(ifr->ifr_data, , sizeof(u32))) {
+ ret = -EFAULT;
+ break;
+ }
if (copy_to_user(ifr->ifr_data + sizeof (u32), lmcEventLogBuf, sizeof
(lmcEventLogBuf)))
-return -EFAULT;
+ ret = -EFAULT;
+ else
+ ret = 0;
-ret = 0;
break;
#endif /* end ifdef _DBG_EVENTLOG */
case LMCIOCT1CONTROL: /*fold01*/
@@ -346,8 +357,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
*/
netif_stop_queue(dev);
-if (copy_from_user(, ifr->ifr_data, sizeof (struct
lmc_xilinx_control)))
-return -EFAULT;
+ if (copy_from_user(, ifr->ifr_data, sizeof(struct
lmc_xilinx_control))) {
+ ret = -EFAULT;
+ break;
+ }
switch(xc.command){
case lmc_xilinx_reset: /*fold02*/
{
-
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: futex strangeness in 2.6.23-mm1/UML
On Mon, 22 Oct 2007 21:11:43 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote: > I have my systems set up to automount my home directory over > NFS when I log in. When trying to log in to the system with > 2.6.23-mm1, I get the messages from above in my syslog, and > the NFS filesystem is not automounted. > > I am thinking something in autofs or the pid-namespace* patches > does not match up and uses a wrong PID number or process pointer > when trying to lock things. > > Which code is at fault I have no idea... I still do not know for sure, but I have found some code that puzzles me. At fork() time, task->pid is set to task->pid->numbers[0].nr On the other hand, fork() returns to the parent process: task->pid[PIDTYPE_PID]->numbers[task->pid->level].nr I have not unravelled the code enough yet to be sure whether this is always the same number, but having a wrong PID number somewhere could certainly explain these autofs4 errors: Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent cache rwlock lock failed Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error: 11 at 65 in cache.c After all, autofs4 puts various kinds of PID information of the daemon into the autofs4 waitqueue: fs/autofs4/waitq.c:296: wq->uid = current->uid; wq->gid = current->gid; wq->pid = current->pid; wq->tgid = current->tgid; Could this be related? Wrt. the UML failures that Miklos is seeing, I imagine UML needs to do some similar tricks. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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/
USB HCD: avoid duplicate local_irq_disable()
usb_hcd_flush_endpoint() has a retry loop that starts with a spin_lock_irq(),
but only gives up the spinlock, not the irq_disable before jumping to the
rescan label.
Split the spin_lock_irq into the retryable part and the local_irq_disable()
that is only done once as a micro-optimization and slight cleanup.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
On Tuesday 23 October 2007, I wrote:
> I tried the trivial annotation below and (with lockdep enabled) got a few
> warnings at boot time, but only one that I could still find in the log
> buffer:
One more such example that was not found by lockdep. I guess this counts
as a false positive, as it is clearly harmless, but working around
it is a small optimization for the case where local_irq_disable()
is a hypervisor call.
Should we try to fix this class of (non-)problem in other places?
Will this patch cause a different warning with lockdep since now we
are pairing spin_lock() with spin_unlock_irq()?
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1312,8 +1312,9 @@ void usb_hcd_flush_endpoint(struct usb_device *udev,
hcd = bus_to_hcd(udev->bus);
/* No more submits can occur */
+ local_irq_disable();
rescan:
- spin_lock_irq(_urb_list_lock);
+ spin_lock(_urb_list_lock);
list_for_each_entry (urb, >urb_list, urb_list) {
int is_in;
-
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 6/8] pull RT tasks
-- On Tue, 23 Oct 2007, Dmitry Adamushko wrote: > Hi Steven, > > agreed with your comments in the previous message. Indeed, I missed some > points. > > > On wakeup, we can wake up several RT tasks (as my test case does) and if > > we only push one task, then the other tasks may not migrate over to the > > other run queues. I logged this happening in my tests. > > I guess, what may happen is that while we are running push_rt_tasks() > on CPU-k (say, as a result on try_to_wake_up(task_1)) > and as this_rq->lock may get released (in double_lock_balance()) , we > may get in a 'race' > with try_to_wake_up(task_2) from (another) CPU-m. > It places a woken up task on the same run-queue (for which > push_rt_task() is already running on CPU-k) and, actually, run > push_rt_task() for the same rq again! > > So it may happen that both task_1 and task_2 will be pushed from the same > CPU... > > Do you see an error in my description? (it's a late hour so I can miss > something again ... sure, otherwise I'm almost perfect :-/ ) Can it > correlate with what you have observed in your tests? > > Otherwise, there is 1:1 relation : push_rt_task() is called for every > new (single) task activated by try_to_wake_up() and for a preempted > task... so it's not like a few tasks are placed on the run-queue and > then push_rt_tasks() is called once. > > btw., if this scenario may take place... maybe it would make sense to > have something like RTLB_INPROGRESS/PENDING and to avoid competing > push_rt_tasks() calls for the same 'rq' from different CPUs? > (although, there can be some disadvantages here as well. e.g. we would > likely need to remove 'max 3 tasks at once' limit and get, > theoretically, unbounded time spent in push_rt_tasks() on a single > CPU). I think I see what you're saying now. That we really should do the push on wakeup, since only the one rt task that is woken up will be able to be pushed. My code may seem a bit aggressive, but from logging, I see that we seldom push more than one task. But if we don't go ahead and push more than one, the rt-migrate-test will sometimes fail. There's funny cases when we need to push more than one. I can't remember exactly what they were, but sometimes because of races between the pushes and pulls where one will miss the fact that an RT process is being queued while its searching to pull a task, but the push will catch it. Or vice versa. The max tries is just a paranoid case where I don't want heavy scheduling to cause an unbounded trying to push or pull tasks. According to the logging while running the rt-migrate-tests, the loop there repeated approximately 1 in 20, and iterated twice 1 in 100 and hit the third loop twice in all my tests (over a 1000 iterations being logged). But logging slows it down and modifies the results itself, and perhaps I'll add statistics soon. I'm about to post a second batch of patches. Thanks, -- Steve - 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] Unlock before return in p9_mux_poll_start
commit 9f822afc65cc094c905901f9d92bf25042f9ed22
Author: Roel Kluin <[EMAIL PROTECTED]>
Date: Tue Oct 23 03:15:55 2007 +0200
Unlock before return in p9_mux_poll_start
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
diff --git a/net/9p/mux.c b/net/9p/mux.c
index f140147..c9f0805 100644
--- a/net/9p/mux.c
+++ b/net/9p/mux.c
@@ -222,8 +222,10 @@ static int p9_mux_poll_start(struct p9_conn *m)
}
if (i >= ARRAY_SIZE(p9_mux_poll_tasks)) {
- if (vptlast == NULL)
+ if (vptlast == NULL) {
+ mutex_unlock(_mux_task_lock);
return -ENOMEM;
+ }
P9_DPRINTK(P9_DEBUG_MUX, "put in proc %d\n", i);
list_add(>mux_list, >mux_list);
-
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: futex strangeness in 2.6.23-mm1/UML
On Mon, 22 Oct 2007 17:16:24 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent > > > > > cache rwlock lock failed > > > > > Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads > > > > > error: 11 at 65 in cache.c > I guess we can debug it in the old-fashioned ways. The first of > which is to palm the problem off on Pavel ;) > > I don't recall seeing a simple step-by-step way by which others can > reproduce this? I have my systems set up to automount my home directory over NFS when I log in. When trying to log in to the system with 2.6.23-mm1, I get the messages from above in my syslog, and the NFS filesystem is not automounted. I am thinking something in autofs or the pid-namespace* patches does not match up and uses a wrong PID number or process pointer when trying to lock things. Which code is at fault I have no idea... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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] Unlock in iTCO_wdt_start when reboot is disabled
commit 61c31efe4e9c34531666a6c5857ecd19c8db
Author: Roel Kluin <[EMAIL PROTECTED]>
Date: Tue Oct 23 03:08:27 2007 +0200
Unlock in iTCO_wdt_start when reboot is disabled
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
diff --git a/drivers/watchdog/iTCO_wdt.c b/drivers/watchdog/iTCO_wdt.c
index cd5a565..185c093 100644
--- a/drivers/watchdog/iTCO_wdt.c
+++ b/drivers/watchdog/iTCO_wdt.c
@@ -300,6 +300,7 @@ static int iTCO_wdt_start(void)
/* disable chipset's NO_REBOOT bit */
if (iTCO_wdt_unset_NO_REBOOT_bit()) {
+ spin_unlock(_wdt_private.io_lock);
printk(KERN_ERR PFX "failed to reset NO_REBOOT flag, reboot
disabled by hardware\n");
return -EIO;
}
-
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/2] irq_flags_t: intro and core annotations
On Monday 22 October 2007, Thomas Gleixner wrote:
> On Mon, 22 Oct 2007, Arnd Bergmann wrote:
>
> > I tried this as well a few years ago, and I think I hit a few places in
> > the early initialization, but nothing unfixable.
>
> Hmm, lockdep checks this already. If it does not catch it, we need to fix it.
I've looked at the lockdep code for some time but couldn't find out how
it is trying to catch this kind of bug. AFAICS, there are all sorts of
really complex spinlock/irqflags interaction problems that lockdep checks
for, but not this really simple one ;-)
I tried the trivial annotation below and (with lockdep enabled) got a few
warnings at boot time, but only one that I could still find in the log
buffer:
[ 10.298910] WARNING: at /home/arnd/linux/linux-2.6/kernel/signal.c:1799
get_signal_to_deliver()
[ 10.298978] [] show_trace_log_lvl+0x1a/0x2f
[ 10.299072] [] show_trace+0x12/0x14
[ 10.299160] [] dump_stack+0x15/0x17
[ 10.299248] [] get_signal_to_deliver+0x73/0x636
[ 10.299338] [] do_notify_resume+0x91/0x728
[ 10.299427] [] work_notifysig+0x13/0x1b
This one looks like in the syscall exit path, after disabling the interrupts,
we call back into a C function that first disables and then enables
interrupts again unconditionally, which seems to do the right thing here,
but still feels wrong.
I suppose lockdep should be extended to catch this kind of bug as well,
instead of the hack I used to find this.
Arnd <><
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index c376f3b..3ece198 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -207,13 +207,8 @@ do {
\
#endif
-#define spin_lock_irq(lock)_spin_lock_irq(lock)
#define spin_lock_bh(lock) _spin_lock_bh(lock)
-
-#define read_lock_irq(lock)_read_lock_irq(lock)
#define read_lock_bh(lock) _read_lock_bh(lock)
-
-#define write_lock_irq(lock) _write_lock_irq(lock)
#define write_lock_bh(lock)_write_lock_bh(lock)
/*
@@ -221,13 +216,25 @@ do {
\
*/
#if defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT) || \
!defined(CONFIG_SMP)
+# define spin_lock_irq(lock) \
+do { WARN_ON_ONCE(irqs_disabled()); _spin_lock_irq(lock); } while (0)
+# define read_lock_irq(lock) \
+do { WARN_ON_ONCE(irqs_disabled()); _read_lock_irq(lock); } while (0)
+# define write_lock_irq(lock) \
+do { WARN_ON_ONCE(irqs_disabled()); _write_lock_irq(lock); } while (0)
# define spin_unlock(lock) _spin_unlock(lock)
# define read_unlock(lock) _read_unlock(lock)
# define write_unlock(lock)_write_unlock(lock)
-# define spin_unlock_irq(lock) _spin_unlock_irq(lock)
-# define read_unlock_irq(lock) _read_unlock_irq(lock)
-# define write_unlock_irq(lock)_write_unlock_irq(lock)
+# define spin_unlock_irq(lock) \
+do { WARN_ON_ONCE(!irqs_disabled()); _spin_unlock_irq(lock); } while (0)
+# define read_unlock_irq(lock) \
+do { WARN_ON_ONCE(!irqs_disabled()); _read_unlock_irq(lock); } while (0)
+# define write_unlock_irq(lock) \
+do { WARN_ON_ONCE(!irqs_disabled()); _write_unlock_irq(lock); } while (0)
#else
+# define spin_lock_irq(lock) _spin_lock_irq(lock)
+# define read_lock_irq(lock) _read_lock_irq(lock)
+# define write_lock_irq(lock) _write_lock_irq(lock)
# define spin_unlock(lock) \
do {__raw_spin_unlock(&(lock)->raw_lock); __release(lock); } while (0)
# define read_unlock(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: Resume problems
> Also box just froze on level 3 but I got a ACPI error at least which I didn't > got in any other dmesg till now : > ( also patch was tested with HT disabled and Suspend and Hibernation enabled > in kernel and BIOS ) > > ... > > Oct 23 01:51:05 lara [ 273.512374] PM: Removing info for No Bus:input0 > Oct 23 01:51:05 lara [ 274.545158] PM: Removing info for No Bus:mouse0 > Oct 23 01:51:05 lara [ 274.551435] PM: Removing info for No Bus:event1 > Oct 23 01:51:05 lara [ 274.559493] PM: Removing info for No Bus:input1 > Oct 23 01:53:06 lara [ 394.869468] ACPI Error (evevent-0303): No installed > handler for fixed event [0002] [20070126] > > > > ( I hard reseted after that ) > > I try level 2 and 1 now I just wanted to let you know. > Same issues with level 2 and 1. BTW I found out why my box does not shutdown with acpi=ht. It seems like libata does not like that acpi mode =) dropping the '... read http://linux-ata.org/shutdown.html , power down manually' message. That works perfectly with full acpi here. After all I think all this problems may be some who ACPI related but the question is why they get triggered by Suspend/Hibernation. If you want me to test something else just let me know. Gabriel - 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] several returns before unlocking in lmc_ioctl
Several returns before unlocking in lmc_ioctl
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 5ea8772..af7b3e4 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -142,9 +142,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
* To date internally, just copy this out to the user.
*/
case LMCIOCGINFO: /*fold01*/
-if (copy_to_user(ifr->ifr_data, >ictl, sizeof (lmc_ctl_t)))
-return -EFAULT;
-ret = 0;
+ if (copy_to_user(ifr->ifr_data, >ictl, sizeof(lmc_ctl_t)))
+ ret = -EFAULT;
+ else
+ ret = 0;
break;
case LMCIOCSINFO: /*fold01*/
@@ -159,8 +160,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
break;
}
-if (copy_from_user(, ifr->ifr_data, sizeof (lmc_ctl_t)))
-return -EFAULT;
+ if (copy_from_user(, ifr->ifr_data, sizeof(lmc_ctl_t))) {
+ ret = -EFAULT;
+ break;
+ }
sc->lmc_media->set_status (sc, );
@@ -190,8 +193,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
break;
}
- if (copy_from_user(_type, ifr->ifr_data, sizeof(u_int16_t)))
-return -EFAULT;
+ if (copy_from_user(_type, ifr->ifr_data, sizeof(u_int16_t))) {
+ ret = -EFAULT;
+ break;
+ }
if (new_type == old_type)
@@ -229,9 +234,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
sc->lmc_xinfo.Magic1 = 0xDEADBEEF;
if (copy_to_user(ifr->ifr_data, >lmc_xinfo,
- sizeof (struct lmc_xinfo)))
-return -EFAULT;
-ret = 0;
+ sizeof(struct lmc_xinfo))) {
+ ret = -EFAULT;
+ else
+ ret = 0;
break;
@@ -262,9 +268,9 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
if (copy_to_user(ifr->ifr_data, >stats,
sizeof (struct lmc_statistics)))
-return -EFAULT;
-
-ret = 0;
+ ret = -EFAULT;
+ else
+ ret = 0;
break;
case LMCIOCCLEARLMCSTATS: /*fold01*/
@@ -292,8 +298,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
break;
}
-if (copy_from_user(, ifr->ifr_data, sizeof (lmc_ctl_t)))
-return -EFAULT;
+ if (copy_from_user(, ifr->ifr_data, sizeof(lmc_ctl_t))) {
+ ret = -EFAULT;
+ break;
+ }
sc->lmc_media->set_circuit_type(sc, ctl.circuit_type);
sc->ictl.circuit_type = ctl.circuit_type;
ret = 0;
@@ -318,12 +326,15 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
#ifdef DEBUG
case LMCIOCDUMPEVENTLOG:
-if (copy_to_user(ifr->ifr_data, , sizeof (u32)))
-return -EFAULT;
+ if (copy_to_user(ifr->ifr_data, , sizeof(u32))) {
+ ret = -EFAULT;
+ break;
+ }
if (copy_to_user(ifr->ifr_data + sizeof (u32), lmcEventLogBuf, sizeof
(lmcEventLogBuf)))
-return -EFAULT;
+ ret = -EFAULT;
+ else
+ ret = 0;
-ret = 0;
break;
#endif /* end ifdef _DBG_EVENTLOG */
case LMCIOCT1CONTROL: /*fold01*/
@@ -346,8 +357,10 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
*/
netif_stop_queue(dev);
-if (copy_from_user(, ifr->ifr_data, sizeof (struct
lmc_xilinx_control)))
-return -EFAULT;
+ if (copy_from_user(, ifr->ifr_data, sizeof(struct
lmc_xilinx_control))) {
+ ret = -EFAULT;
+ break;
+ }
switch(xc.command){
case lmc_xilinx_reset: /*fold02*/
{
@@ -618,8 +631,8 @@ int lmc_ioctl (struct net_device *dev, struct ifreq *ifr,
int cmd) /*fold00*/
}
spin_unlock_irqrestore(>lmc_lock, flags); /*fold01*/
-
-lmc_trace(dev, "lmc_ioctl out");
+if (ret >= 0)
+ lmc_trace(dev, "lmc_ioctl out");
return ret;
}
-
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/2] CFS CGroup: Code cleanup
Clean up some CFS CGroup code
- replace "cont" with "cgrp" in a few places in the CFS cgroup code,
- use write_uint rather than write for cpu.shares write function
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/sched.c | 51 +--
1 file changed, 17 insertions(+), 34 deletions(-)
Index: container-2.6.23-mm1/kernel/sched.c
===
--- container-2.6.23-mm1.orig/kernel/sched.c
+++ container-2.6.23-mm1/kernel/sched.c
@@ -6936,25 +6936,25 @@ unsigned long sched_group_shares(struct
#ifdef CONFIG_FAIR_CGROUP_SCHED
/* return corresponding task_group object of a cgroup */
-static inline struct task_group *cgroup_tg(struct cgroup *cont)
+static inline struct task_group *cgroup_tg(struct cgroup *cgrp)
{
- return container_of(cgroup_subsys_state(cont, cpu_cgroup_subsys_id),
-struct task_group, css);
+ return container_of(cgroup_subsys_state(cgrp, cpu_cgroup_subsys_id),
+ struct task_group, css);
}
static struct cgroup_subsys_state *
-cpu_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
+cpu_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cgrp)
{
struct task_group *tg;
- if (!cont->parent) {
+ if (!cgrp->parent) {
/* This is early initialization for the top cgroup */
- init_task_group.css.cgroup = cont;
+ init_task_group.css.cgroup = cgrp;
return _task_group.css;
}
/* we support only 1-level deep hierarchical scheduler atm */
- if (cont->parent->parent)
+ if (cgrp->parent->parent)
return ERR_PTR(-EINVAL);
tg = sched_create_group();
@@ -6962,21 +6962,21 @@ cpu_cgroup_create(struct cgroup_subsys *
return ERR_PTR(-ENOMEM);
/* Bind the cgroup to task_group object we just created */
- tg->css.cgroup = cont;
+ tg->css.cgroup = cgrp;
return >css;
}
static void cpu_cgroup_destroy(struct cgroup_subsys *ss,
- struct cgroup *cont)
+ struct cgroup *cgrp)
{
- struct task_group *tg = cgroup_tg(cont);
+ struct task_group *tg = cgroup_tg(cgrp);
sched_destroy_group(tg);
}
static int cpu_cgroup_can_attach(struct cgroup_subsys *ss,
-struct cgroup *cont, struct task_struct *tsk)
+struct cgroup *cgrp, struct task_struct *tsk)
{
/* We don't support RT-tasks being in separate groups */
if (tsk->sched_class != _sched_class)
@@ -6986,38 +6986,21 @@ static int cpu_cgroup_can_attach(struct
}
static void
-cpu_cgroup_attach(struct cgroup_subsys *ss, struct cgroup *cont,
+cpu_cgroup_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct cgroup *old_cont, struct task_struct *tsk)
{
sched_move_task(tsk);
}
-static ssize_t cpu_shares_write(struct cgroup *cont, struct cftype *cftype,
- struct file *file, const char __user *userbuf,
- size_t nbytes, loff_t *ppos)
+static int cpu_shares_write_uint(struct cgroup *cgrp, struct cftype *cftype,
+ u64 shareval)
{
- unsigned long shareval;
- struct task_group *tg = cgroup_tg(cont);
- char buffer[2*sizeof(unsigned long) + 1];
- int rc;
-
- if (nbytes > 2*sizeof(unsigned long))/* safety check */
- return -E2BIG;
-
- if (copy_from_user(buffer, userbuf, nbytes))
- return -EFAULT;
-
- buffer[nbytes] = 0; /* nul-terminate */
- shareval = simple_strtoul(buffer, NULL, 10);
-
- rc = sched_group_set_shares(tg, shareval);
-
- return (rc < 0 ? rc : nbytes);
+ return sched_group_set_shares(cgroup_tg(cgrp), shareval);
}
-static u64 cpu_shares_read_uint(struct cgroup *cont, struct cftype *cft)
+static u64 cpu_shares_read_uint(struct cgroup *cgrp, struct cftype *cft)
{
- struct task_group *tg = cgroup_tg(cont);
+ struct task_group *tg = cgroup_tg(cgrp);
return (u64) tg->shares;
}
-
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] CFS CGroup: Report usage
Report CPU usage in CFS Cgroup directories
Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
milliseconds for that cgroup's tasks
This replaces the "example CPU Accounting CGroup subsystem" that
was merged into mainline last week.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/sched.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
Index: container-2.6.23-mm1/kernel/sched.c
===
--- container-2.6.23-mm1.orig/kernel/sched.c
+++ container-2.6.23-mm1/kernel/sched.c
@@ -7005,15 +7005,37 @@ static u64 cpu_shares_read_uint(struct c
return (u64) tg->shares;
}
-static struct cftype cpu_shares = {
- .name = "shares",
- .read_uint = cpu_shares_read_uint,
- .write_uint = cpu_shares_write_uint,
+static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
+{
+ struct task_group *tg = cgroup_tg(cgrp);
+ int i;
+ u64 res = 0;
+ for_each_possible_cpu(i) {
+ unsigned long flags;
+ spin_lock_irqsave(>cfs_rq[i]->rq->lock, flags);
+ res += tg->se[i]->sum_exec_runtime;
+ spin_unlock_irqrestore(>cfs_rq[i]->rq->lock, flags);
+ }
+ /* Convert from ns to ms */
+ do_div(res, 100);
+ return res;
+}
+
+static struct cftype cpu_files[] = {
+ {
+ .name = "shares",
+ .read_uint = cpu_shares_read_uint,
+ .write_uint = cpu_shares_write_uint,
+ },
+ {
+ .name = "usage",
+ .read_uint = cpu_usage_read,
+ },
};
static int cpu_cgroup_populate(struct cgroup_subsys *ss, struct cgroup *cont)
{
- return cgroup_add_file(cont, ss, _shares);
+ return cgroup_add_files(cont, ss, cpu_files, ARRAY_SIZE(cpu_files));
}
struct cgroup_subsys cpu_cgroup_subsys = {
-
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/2] CFS CGroup: cleanup & usage reporting
These two patches consist of a small cleanup to CFS, and adding a control file reporting CPU usage in milliseconds in each CGroup directory. They're just bundled together since the second patch depends slightly on the cleanups in the first patch. - 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/9] Unionfs: security convert lsm into a static interface fix
In message <[EMAIL PROTECTED]>, Christoph Hellwig writes:
> On Sun, Oct 21, 2007 at 07:51:14PM -0400, Erez Zadok wrote:
> > From: Andrew Morton <[EMAIL PROTECTED]>
> >
> > ERROR: "security_inode_permission" [fs/unionfs/unionfs.ko] undefined!
> > ERROR: "security_file_ioctl" [fs/unionfs/unionfs.ko] undefined!
> >
> > Need these back.
>
> These should never used by modules.
Why? Are you concerned that the security policy may change after a module
is loaded? My understanding of the security code is that it should handle
this, even if people call security_*() functions directly. When I look at
the security_* functions in security.c, to me they very much smell like
global wrappers that others can call, b/c they refer to private/global ops
vectors that one should not be referencing directly. For example:
int security_file_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
return security_ops->file_ioctl(file, cmd, arg);
}
> You'll need to use and/or introduce
> vfs_ helpers that do proper security checks before calling the methods.
I can probably get rid of having unionfs call security_inode_permission, by
calling permission() myself and carefully post-process its return code
(unionfs needs to "ignore" EROFS initially, to allow copyup to take place).
But security_file_ioctl doesn't have any existing helper I can call. I can
introduce a trivial vfs_security_file_ioctl wrapper to security_file_ioctl,
but what about the already existing *19* exported security_* functions in
security/security.c? Do you want to see simple wrappers for all of them?
It seems redundant to add a one-line wrapper around an already one-line
function around security_ops->XXX. Plus, some of the existing exported
security_* functions are file-system related, others are networking, etc. So
we'll need wrappers whose names are prefixed appropriately: vfs_*, net_*,
etc.
Thanks,
Erez.
-
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: Interaction between Xen and XFS: stray RW mappings
On Tue, Oct 23, 2007 at 01:35:14AM +0200, Andi Kleen wrote: > On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote: > > On Mon, Oct 22, 2007 at 09:07:40PM +0200, Andi Kleen wrote: > > > It's hidden now so it causes any obvious failures any more. Just subtle > > > ones which is much worse. > > > > There's no evidence of any problems ever being caused by this code. . > Also the corruption will not be on the XFS side, but on the uncached mapping > so typically some data sent to some device gets a few corrupted cache line > sized blocks. Depending on the device this might also not be fatal -- e.g. > if it is texture data some corrupted pixels occasionally are not that > visible. But there can be still cases where it can cause real failures when > it hits something critical (the failures were it was tracked down was > usually it hitting some command ring and the hardware erroring out) There seems to be little evidence of that occurring around the place. > > It's been there for years. > > That doesn't mean it is correct. Right, but it also points to the fact that it's not causing problems from 99.999% of ppl out there. > Basically you're saying: I don't care if I corrupt device driver data. > That's not a very nice thing to say. No, I did not say that. I said that there's no evidence that points to this causing problems anywhere. > > > But why not just disable it? It's not critical functionality, just a > > > optimization that unfortunately turned out to be incorrect. > > > > It is critical functionality for larger machines because vmap()/vunmap() > > really does suck in terms of scalability. > > Critical perhaps, but also broken. > > And if it's that big a problem would it be really that difficult to change > only the time critical paths using it to not? I assume it's only the > directory code where it is a problem? That would be likely even faster in > general. Difficult - yes. All the btree code in XFS would have to be rewritten to remove the assumption that the buffer structures are contiguous in memory. Any bug we introduce in doing this will result in on disk corruption, which is far worse than occasionally crashing a machine with a stray mapping. > > > It could be made correct short term by not freeing the pages until > > > vunmap for example. > > > > Could vmap()/vunmap() take references to the pages that are mapped? That > > way delaying the unmap would also delay the freeing of the pages and hence > > we'd have no problems with the pages being reused before the mapping is > > torn down. That'd work for Xen even with XFS's lazy unmapping scheme, and > > would allow Nick's more advanced methods to work as well > > You could always just keep around an array of the pages and then drop the > reference count after unmap. Or walk the vmalloc mapping and generate such > an array before freeing, then unmap and then drop the reference counts. You mean like vmap() could record the pages passed to it in the area->pages array, and we walk and release than in __vunmap() like it already does for vfree()? If we did this, it would probably be best to pass a page release function into the vmap or vunmap call - we'd need page_cache_release() called on the page rather than __free_page() The solution belongs behind the vmap/vunmap interface, not in XFS Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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] 9p: v9fs_vfs_rename incorrect clunk order
In v9fs_vfs_rename function labels don't match the fids that are clunked. The correct clunk order is clunking newdirfid first and then olddirfid next. Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]> --- commit 0c9269a1384273b7a409a2163fdf91cd39092889 tree 8a4984196ccb7ed027c086a53866e5582835e61f parent 55b70a0300b873c0ec7ea6e33752af56f41250ce author Latchesar Ionkov <[EMAIL PROTECTED]> Mon, 22 Oct 2007 18:11:19 -0600 committer Latchesar Ionkov <[EMAIL PROTECTED]> Mon, 22 Oct 2007 18:11:19 -0600 fs/9p/vfs_inode.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c index 175b4d9..23581bc 100644 --- a/fs/9p/vfs_inode.c +++ b/fs/9p/vfs_inode.c @@ -687,10 +687,10 @@ v9fs_vfs_rename(struct inode *old_dir, struct dentry *old_dentry, retval = p9_client_wstat(oldfid, ); clunk_newdir: - p9_client_clunk(olddirfid); + p9_client_clunk(newdirfid); clunk_olddir: - p9_client_clunk(newdirfid); + p9_client_clunk(olddirfid); done: return retval; - 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/2] irq_flags_t: intro and core annotations
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 16:47:16 -0400 > Let me add to the chorus of voices: I continually see two cases where > real bugs crop up: > > 1) hacker uses spin_lock_irq() in incorrect context (where it is not > safe to do a blind enable/disable) > > 2) hacker uses spin_lock_irq() correctly, but the surrounding code > changes, thus invalidating prior assumptions. > > I would even go so far as to support the drastic measure of deleting > spin_lock_irq(). > > spin_lock_irqsave() generates fewer bugs, is more future-proof, and by > virtue of 'flags' permits architectures a bit more flexibility. Whilst I agree with you fully on the error-prone'ness argument, reading the processor interrupt level to fill in the 'flags' can have non-trivial cost. I think it's about 9 cycles and a full pipeline flush on most sparc64 chips for example. The write to turn off interrupts costs about the same, so you'd essentially be doubling the execution cost in every case that you convert as you propose. I seem to recall that on modern x86 chips the cost of dorking around with eflags like this is even higher. What's the relative cost of pushfl/popl/pushl/popfl vs. cli/sti on like a core2 duo or a k8? For 64-bit powerpc's software interrupt disabling scheme it seems to cost is about equal for both cases. - 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] return hidden bug
On 10/23/2007 01:00 AM, Ray Lee wrote: On 10/22/07, Rene Herman <[EMAIL PROTECTED]> wrote: Hugely trust inspiring isn't it -- the amount of eyes and comments you'll get even on trivial patches like this? This development model is working! Go easy with the snarkiness, hmm? It's the trivial ones that seem to be the most dangerous. The larger ones actually get *tested* sometimes. I was also commenting and don't generally on anything much more involved so any snarkiness included myself which should make things better. Now if only we'd sometimes get some for non trivial patches as well... That's certainly true regardless, but for myself, I'd rather throw some reviews out for the small ones since I have adequate time and knowledge for them. The larger ones require domain specific knowledge I lack, and time I don't have. Exactly the problem. Comment was mostly triggered due to me looking at a problem with a proprietary CD-ROM driver again tonight that I posted a few months ago where the only comment has been from the fellow author. There the problem was the block layer blowing up and given that it seems unlikely that this wouldn't be a problem inside the newbie-driver itself, that the block part of it was actually really small and people said they'd look at it, the subsequent thundering silence still annoys me. Ofcourse, now it seems the kernel itself has moved on enough that the driver doesn't work at _all_ anymore and I at the moment lack the time to spend the required hours googling around trying to find out what the heck changed out from under me so that I might get it to at least do what it already did do. Hey, I don't actually know and maybe I'm just wrong but I have the feeling that over the last 1 or 2 years most new developers seem to be either people that are payed to be so, perhaps in the form of graduation, or janitors. The kernel is much, much more complex than even only a few years ago and at the same time the number of knowledgeable developers who'll do something other than their own thing and otherwise just wait around for something perfect to merge seems to be approaching zero. That is -- I do not feel that the current developer base is expending overly many efforts to appear welcoming. Please feel free to do the open-source thing and argue that's actually an advantage (there we have that snarkiness again...) or otherwise ignore me. I'll just sit here and be grumpy anyway. Might be better after a good night's sleep... Rene. - 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: futex strangeness in 2.6.23-mm1/UML
On Mon, 22 Oct 2007 20:07:42 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote: > On Mon, 22 Oct 2007 17:29:26 -0400 > Rik van Riel <[EMAIL PROTECTED]> wrote: > > > On Mon, 22 Oct 2007 22:48:51 +0200 > > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > > > > I'm getting a process stuck in pthread_rwlock_wrlock(), even > > > > > though it looks like the lock is not held by anybody. > > > > > > > > > > I think the last -mm was OK. Any ideas? > > > > > > > > > > If not, I'll go searching for the offending patch. > > > > > > > > I wonder if that's the same bug that's breaking autofs for me. > > > > > > Probably. > > > > > > > Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent > > > > cache rwlock lock failed > > > > Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error: > > > > 11 at 65 in cache.c > > > > > > > > I'm bisecting 2.6.23-mm1 today to find the problem patch, with > > > > some luck I'll have it this afternoon. > > > > > > > > With the series applied up to > > > > whitespace-fixes-task-exit-handling.patch things work. > > > > > > > > It breaks before > > > > kswapd-should-only-wait-on-io-if-there-is-io.patch > > > > > > > > That leaves only about 60-80 patches to look at :) > > > > > > OK, the first patch that breaks something for me is: > > > > > > pid-namespaces-move-alloc_pid-lower-in-copy_process.patch > > > > Confirmed. That same patch is the point where the bisect > > here starts breaking autofs. > > Oww man. Getting into heisenbug territory now :( > > I bisected down to the point where I had these two patches between > good and bad: > > # GOOD > pid-namespaces-move-alloc_pid-lower-in-copy_process.patch > pid-namespaces-make-proc-have-multiple-superblocks-one-for-each-namespace.patch > # BAD > > Applying them one by one and rebuilding the kernel after each one > gave me a working kernel, though! > > Bisecting them from the top (quilt pop) resulted in a broken kernel, > bisecting from the bottom (quilt push) results in a working one. > > I have no idea what is going on any more... > I guess we can debug it in the old-fashioned ways. The first of which is to palm the problem off on Pavel ;) I don't recall seeing a simple step-by-step way by which others can reproduce this? - 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: Interaction between Xen and XFS: stray RW mappings
On Tue, 2007-10-23 at 01:35 +0200, Andi Kleen wrote: > On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote: > > On Mon, Oct 22, 2007 at 09:07:40PM +0200, Andi Kleen wrote: > > > On Mon, Oct 22, 2007 at 11:40:52AM -0700, Jeremy Fitzhardinge wrote: > > > > Andi Kleen wrote: > > > > > Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > > > > > > > > > >> Yes, that's precisely the problem. xfs does delay the unmap, leaving > > > > >> stray mappings, which upsets Xen. > > > > >> > > > > > > > > > > Again it not just upsets Xen, keeping mappings to freed pages is > > > > > wrong generally > > > > > and violates the x86 (and likely others like PPC) architecture > > > > > because it can > > > > > cause illegal caching attribute aliases. It is a serious offense to leave stray mappings for memory which can get re-mapped to I/O devices... especially with PCI and other device hotplug. I have to back up Andi on this one unconditionally. On architectures where you have multibyte, non-wordsize updates to hardware page tables, you even have races here when setting, updating and clearing PTEs that must be done in a sequence where no aliasing of mappings to partially written PTEs can result in I/O memory getting mapped in a cacheable state. The window here is only one instruction, and yes, it is possible for a window this small to create a problem. A large (or permanently lazy) window is extremely frightening. These things do cause bugs. The bugs take a very long time to show up and are very difficult to track down, since they can basically cause random behavior, such as hanging the machine or losing orbit and crashing into the moon. Zach - 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] PCI: disable MSI on more ATI NorthBridges
From: Daniel Barkalow <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 17:31:04 -0400 (EDT) > It's likewise documented (although maybe arguable in wording) that the > device shouldn't send legacy interrupts if MSI is in use, regardless of > INTX_DISABLE, but this also happens in the field. > > I think that the current Linux behavior with respect to INTX_DISABLE is > simply due to which hardware bug was present in the device whose driver > first got Linux support, but one or the other or both needs a quirk, since > there's no behavior that works with everything. And it's still impossible > to tell which bug is more common, since MSI isn't used most of the time, > even if the hardware supports it, so it's pretty arbitrary which way Linux > goes in the non-quirk case. I think this pretty much sums up the situation accurately. My suggestion is: 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets a flag in the pci_dev. 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this flag from #2 is set. 4) Add quirk entries for drivers/net/tg3.c chips and these SATA devices we are learning about here, as well as any others we are aware of right now. 5) Remove the pci_intx() workaround code from drivers/net/tg3.c and elsewhere. - 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: Resume problems
Gabriel C wrote: > Rafael J. Wysocki wrote: >> On Tuesday, 23 October 2007 01:00, Gabriel C wrote: >>> Rafael J. Wysocki wrote: On Monday, 22 October 2007 18:15, Gabriel C wrote: > Hi all , > > I'm running current git + aic7xxx suspend patch from > http://bugzilla.kernel.org/show_bug.cgi?id=3062 > on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ). > > Suspend works fine but on resume I have some problems. > All CPU's but boot CPU won't come back , everything else seems fine. Can you please try to disable HT and suspend? >>> So only 'Hibernation' is enabled in kernel and HT disabled in BIOS ? >>> >>> If you mean that , sure I can try doing so. >> With suspend or hibernation enabled in the kernel, but with HT disabled in >> the >> BIOS. > > Ok trying in some minutes. Disabling HT does not make any difference , nor disabling / enabling only one Hibernation or Suspend in kernel and BIOS nor any combination of these. > >>> I also could disable Suspend to RAM completly from BIOS as well if you want. >> No, that rather won't work. >> > ... > > Oct 22 15:02:28 lara [ 49.618795] Enabling non-boot CPUs ... > Oct 22 15:02:28 lara [ 49.622211] PM: Adding info for No Bus:msr1 > Oct 22 15:02:28 lara [ 49.622259] PM: Adding info for No Bus:cpu1 > Oct 22 15:02:28 lara [ 49.622302] SMP alternatives: switching to SMP > code > Oct 22 15:02:28 lara [ 49.623536] Booting processor 1/1 eip 3000 > Oct 22 15:02:28 lara [ 54.638093] Not responding. > Oct 22 15:02:28 lara [ 54.638096] Inquiring remote APIC #1... > Oct 22 15:02:28 lara [ 54.638099] ... APIC #1 ID: failed > Oct 22 15:02:28 lara [ 54.638204] ... APIC #1 VERSION: failed > Oct 22 15:02:28 lara [ 54.638307] ... APIC #1 SPIV: failed > Oct 22 15:02:28 lara [ 54.638427] skipping cpu1, didn't come online > Oct 22 15:02:28 lara [ 54.638602] PM: Removing info for No Bus:msr1 > Oct 22 15:02:28 lara [ 54.638643] PM: Removing info for No Bus:cpu1 > Oct 22 15:02:28 lara [ 54.638678] Error taking CPU1 up: -5 > Oct 22 15:02:28 lara [ 54.640908] PM: Adding info for No Bus:msr2 > Oct 22 15:02:28 lara [ 54.640939] PM: Adding info for No Bus:cpu2 > Oct 22 15:02:28 lara [ 54.640976] SMP alternatives: switching to SMP > code > Oct 22 15:02:28 lara [ 54.641961] Booting processor 2/2 eip 3000 > Oct 22 15:02:28 lara [ 59.656795] Not responding. > Oct 22 15:02:28 lara [ 59.656799] Inquiring remote APIC #2... > Oct 22 15:02:28 lara [ 59.656803] ... APIC #2 ID: failed > Oct 22 15:02:28 lara [ 59.656907] ... APIC #2 VERSION: failed > Oct 22 15:02:28 lara [ 59.657011] ... APIC #2 SPIV: failed > Oct 22 15:02:28 lara [ 59.657131] skipping cpu2, didn't come online > Oct 22 15:02:28 lara [ 59.657300] PM: Removing info for No Bus:msr2 > Oct 22 15:02:28 lara [ 59.657343] PM: Removing info for No Bus:cpu2 > Oct 22 15:02:28 lara [ 59.657379] Error taking CPU2 up: -5 > Oct 22 15:02:28 lara [ 59.659605] PM: Adding info for No Bus:msr3 > Oct 22 15:02:28 lara [ 59.659637] PM: Adding info for No Bus:cpu3 > Oct 22 15:02:28 lara [ 59.659673] SMP alternatives: switching to SMP > code > Oct 22 15:02:28 lara [ 59.660725] Booting processor 3/3 eip 3000 > Oct 22 15:02:28 lara [ 64.675517] Not responding. > Oct 22 15:02:28 lara [ 64.675520] Inquiring remote APIC #3... > Oct 22 15:02:28 lara [ 64.675524] ... APIC #3 ID: failed > Oct 22 15:02:28 lara [ 64.675628] ... APIC #3 VERSION: failed > Oct 22 15:02:28 lara [ 64.675731] ... APIC #3 SPIV: failed > Oct 22 15:02:28 lara [ 64.675859] skipping cpu3, didn't come online > Oct 22 15:02:28 lara [ 64.676017] PM: Removing info for No Bus:msr3 > Oct 22 15:02:28 lara [ 64.676059] PM: Removing info for No Bus:cpu3 > Oct 22 15:02:28 lara [ 64.676092] Error taking CPU3 up: -5 > Oct 22 15:02:28 lara [ 64.676326] evxfevnt-0079 [00] enable >: System is already in ACPI mode > > ... > > After I've played with a lot boot options I found out booting with ' > acpi=ht ' will make the CPU's work again but now > I have a problem on Suspend. Everything seems to just go down disks etc > but the box itself is for some reason still on. > So I've tested reboot=<> options with no luck. > ( after waiting 5 minutes to be sure everything is really off I can just > hit power button). On resume now everything is fine. > > I'm not really sure what is wrong here acpi/hibernation/cpu-hotplug or a > mix of all so I'm CC'ing linux-acpi as well. > The only thing I noticed is the 'Breaking affinity for irq XX' on suspend > without acpi=ht messages. > > I can't even tell whatever other kernel versions are working because > aic7xxx driver didn't got suspend support till now > (
Re: [PATCH 09/10] Change table chaining layout
Matt Mackall wrote: On Mon, Oct 22, 2007 at 11:52:51PM +0100, Alan Cox wrote: On Mon, 22 Oct 2007 16:47:07 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote: On Mon, Oct 22, 2007 at 05:21:30PM -0400, Jeff Garzik wrote: Alan Cox wrote: Why can't we just make the list one item longer than the entry count and stick a NULL on the end of it like normal people ? Certainly seems safer than the current "let's run off the end of the list if anything bad happens" setup... And I do not think allocating n+1 scatterlist entries will have much of a negative impact. It'll mean m-1 scatterlists fit on a slab. Is that really a credible space issue ? Yes. Especially if m is 2 or 1. A scatterlist on 64-bit x86 looks like it takes 32 bytes, which means 128 elements fit on a page. One more spills - ouch! ...and its trivial to reduce that number to 127 without noticeable effect, really. Jeff - 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/
