bugreport

bugreport

[Artem Bityuckiy]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Hello.

There is a bug in jffs2 module registration function - super.c line 293: 
the init_jffs2_fs function doesn't properly perform
the de-initialization in case of failures on lines 315 and 321.

The jffs2_inode_cachep is also not feed.

The proposed patch is attached.

Note 1: I didn't test this patch and didn't even compile JFFS2 with it - 
*be careful*.

Note 2: The similar ought to be fixed in super-v24.c

Artem.

-- 
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind@oktetlabs.ru, web: http://www.oktetlabs.ru

[-- Attachment #2: super.c.diff --]
[-- Type: text/plain, Size: 592 bytes --]

--- super.c	2004-07-18 18:44:42.000000000 +0400
+++ /home/dedekind/tmp/super_fixed.c	2004-07-26 15:05:34.000000000 +0400
@@ -318,7 +318,7 @@
 	ret = jffs2_compressors_init();
 	if (ret) {
 		printk(KERN_ERR "JFFS2 error: Failed to initialise compressors\n");
-		goto out;
+		goto out_proc;
 	}
 	ret = jffs2_create_slab_caches();
 	if (ret) {
@@ -336,10 +336,12 @@
 	jffs2_destroy_slab_caches();
  out_compressors:
 	jffs2_compressors_exit();
+ out_proc:
 #ifdef CONFIG_JFFS2_PROC
         jffs2_proc_exit();
 #endif
  out:
+        kmem_cache_destroy(jffs2_inode_cachep);
 	return ret;
 }
 

bugreport

[Artem B. Bityuckiy]

Hello.

There is a bug in jffs2 module registration function - super.c line 293:
the init_jffs2_fs function doesn't properly perform
the de-initialization in case of failures on lines 315 and 321.
The jffs2_inode_cachep is also not feed.

I Tried to send a patch bit mailman soesn't gieve me...

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: bugreport

[Thomas Gleixner]

On Tue, 2004-07-27 at 15:08, Artem B. Bityuckiy wrote:
> Hello.
> 
> There is a bug in jffs2 module registration function - super.c line 293:
> the init_jffs2_fs function doesn't properly perform
> the de-initialization in case of failures on lines 315 and 321.
> The jffs2_inode_cachep is also not feed.
> 
> I Tried to send a patch bit mailman soesn't gieve me...  

I think you meant that one, right ?

Thanks, fixed in CVS

tglx


@@ -330,6 +330,7 @@
  out_compressors:
        jffs2_compressors_exit();
  out:
+       kmem_cache_destroy(jffs2_inode_cachep);
        return ret;
 }

Re: bugreport

[Artem B. Bityuckiy]

Thomas Gleixner wrote:
> On Tue, 2004-07-27 at 15:08, Artem B. Bityuckiy wrote:
> 
>>Hello.
>>
>>There is a bug in jffs2 module registration function - super.c line 293:
>>the init_jffs2_fs function doesn't properly perform
>>the de-initialization in case of failures on lines 315 and 321.
>>The jffs2_inode_cachep is also not feed.
>>
>>I Tried to send a patch bit mailman soesn't gieve me...  
> 
> 
> I think you meant that one, right ?
> 
> Thanks, fixed in CVS
> 
> tglx
> 
> 
> @@ -330,6 +330,7 @@
>   out_compressors:
>         jffs2_compressors_exit();
>   out:
> +       kmem_cache_destroy(jffs2_inode_cachep);
>         return ret;
>  }
> 
Not only. The "go out" in case of jffs2_compressors_init() failure 
doesn't free /proc resources...

I tried to send the following patch as the attached file (now I'll try
to just insert the text):


-- super.c	2004-07-18 18:44:42.000000000 +0400
+++ /home/dedekind/tmp/super_fixed.c	2004-07-26 15:05:34.000000000 +0400
@@ -318,7 +318,7 @@
  	ret =
  	if (ret) {
  		printk(KERN_ERR "JFFS2 error: Failed to initialise compressors\n");
-		goto out;
+		goto out_proc;
  	}
  	ret = jffs2_create_slab_caches();
  	if (ret) {
@@ -336,10 +336,12 @@
  	jffs2_destroy_slab_caches();
   out_compressors:
  	jffs2_compressors_exit();
+ out_proc:
  #ifdef CONFIG_JFFS2_PROC
          jffs2_proc_exit();
  #endif
   out:
+        kmem_cache_destroy(jffs2_inode_cachep);
  	return ret;
  }


Note - the patch is just to show the problem and doesn't pretent to be 
applied as is.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: bugreport

[Thomas Gleixner]

On Tue, 2004-07-27 at 16:40, Artem B. Bityuckiy wrote:
> Not only. The "go out" in case of jffs2_compressors_init() failure 
> doesn't free /proc resources...

proc support was removed in meantime (current CVS).
But anyway thanks for pointing this out

tglx

Re: bugreport

[Artem B. Bityuckiy]

Thomas Gleixner wrote:
> On Tue, 2004-07-27 at 16:40, Artem B. Bityuckiy wrote:
> proc support was removed in meantime (current CVS).
Oh, sorry, my snapshot was deprecated.

Note, the same thing should also be fixed in super-v24.c.

Just interesting, why the proc interface was removed? Have you added 
ioctl interface? My JFFS2 CVS snapshot of 15 Jul 2004 has no ioctl 
interface.

> But anyway thanks for pointing this out
Not at all.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: bugreport

[David Woodhouse]

On Wed, 2004-07-28 at 10:41 +0400, Artem B. Bityuckiy wrote:
> Just interesting, why the proc interface was removed? Have you added 
> ioctl interface? My JFFS2 CVS snapshot of 15 Jul 2004 has no ioctl 
> interface.

Al Viro took a brief look at it and used lots of nasty works. So I
removed it.

-- 
dwmw2

Bugreport

[Amelia Nilsson]

Hey,
I've found a bug in 2.6.11.6. I have a Toshiba laptop and when i did run 2.6.11.6 my touchpad flipped out, it clicked everywhere when it wasn't supposed to click. I couldn't even move my mouse without it was clicking all over. It works fine i 2.6.10 though. Is there any changes made that can affect this? (I haven't tried 2.6.11.7 yet...)

Best regards,
Amelia Nilsson

Re: Bugreport

[Chris Wright]

* Amelia Nilsson (dhakela@linuxchick.se) wrote:
> I've found a bug in 2.6.11.6. I have a Toshiba laptop and when i did
> run 2.6.11.6 my touchpad flipped out, it clicked everywhere when it
> wasn't supposed to click. I couldn't even move my mouse without it was
> clicking all over. It works fine i 2.6.10 though. Is there any changes
> made that can affect this? (I haven't tried 2.6.11.7 yet...)

2.6.11.7 has no significant changes that should effect your touchpad.
We'll need much more information to make any headway here (see
REPORTING-BUGS).  I've got a Toshiba laptop, and have no issues with the
touchpad.  I assume this is an issue in just in X.  Do you see any obvious
difference in the Xorg.0.log when starting X on the two different kernels?
Any interesting dmesg output on the failing kernel?  Does booting with
psmouse.proto=exps help (assuming you have CONFIG_MOUSE_PS2=y)?

thanks,
-chris

bugreport

[Dmitriy Bukach]

hi


[71287.717849] process `sysctl' is using deprecated sysctl (syscall)
net.ipv6.neigh.bond0.base_reachable_time; Use
net.ipv6.neigh.bond0.base_reachable_time_ms instead.
[71287.720563] sysctl: The scan_unevictable_pages
sysctl/node-interface has been disabled for lack of a legitimate use
case.  If you have one, please send an email to linux-mm@kvack.org.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

bugreport

[Ole M]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
* open Git Gui in a repository from git bash ($ git gui&)
* select some text in the diff pane

What did you expect to happen? (Expected behavior)
* selected text should be highlighted with white text on blue
background (maybe it used to use system defined colors?)

What happened instead? (Actual behavior)
* selected text is highlighted with white text on black background

What's different between what you expected and what actually happened?
* The contrast has increased to a level that is painful for me to look
at, making it difficult to read the selected text.
* It also makes the experience of this tool different from gitk,
making me focus on the tool rather than the content and workflow.

Anything else you want to add:


Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.29.2.windows.2
cpu: x86_64
built from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
uname: Windows 10.0 18363
compiler info: gnuc: 10.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


[Enabled Hooks]

Re: bugreport

[Stefan Haller]

On 02.12.20 11:08, Ole M wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> 
> What did you do before the bug happened? (Steps to reproduce your issue)
> * open Git Gui in a repository from git bash ($ git gui&)
> * select some text in the diff pane
> 
> What did you expect to happen? (Expected behavior)
> * selected text should be highlighted with white text on blue
> background (maybe it used to use system defined colors?)
> 
> What happened instead? (Actual behavior)
> * selected text is highlighted with white text on black background

Hi Ole,

thanks for the report. It's a known bug, a fix for this is already in
the works.

Best,
Stefan


> What's different between what you expected and what actually happened?
> * The contrast has increased to a level that is painful for me to look
> at, making it difficult to read the selected text.
> * It also makes the experience of this tool different from gitk,
> making me focus on the tool rather than the content and workflow.
> 
> Anything else you want to add:
> 
> 
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
> 
> 
> [System Info]
> git version:
> git version 2.29.2.windows.2
> cpu: x86_64
> built from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Windows 10.0 18363
> compiler info: gnuc: 10.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
> 
> 
> [Enabled Hooks]
> 

bugreport

[galo joel]

[-- Attachment #1.1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #1.2: Type: text/html, Size: 26 bytes --]

[-- Attachment #2: git-bugreport-2023-10-24-2215.txt --]
[-- Type: text/plain, Size: 1442 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

execute as admin git bash and,(in cmd W10, same. open git-bash.exe as system-32).
try chmod 755, 777... does not work 'cause im user ($) and not admin (#)

Wha did you expect to happen? (Expected behavior)

change .sh to chmod 755 for execute bash

What happened instead? (Actual behavior)

nothing ._.

What's different between what you expected and what actually happened?

i expected a good sript in bash. now i'm sad

Anything else you want to add:

Please tell me what happen, maybe i'm wrong but chatGPT also no have idea why 
i cannot be admin in my own laptop xD, or maybe i need some libraries that i didnot
install. I sell all my information so please help me to understand why does not work :)

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.42.0.windows.2
cpu: x86_64
built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19045 
compiler info: gnuc: 13.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


[Enabled Hooks]
not run from a git repository - no hooks to show

Re: bugreport

[Thomas Guyot]

Hi Joel,

I'm copying your attachment in-line for simplicity...

On 2023-10-24 16:40, galo joel wrote:
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> execute as admin git bash and,(in cmd W10, same. open git-bash.exe as system-32).
> try chmod 755, 777... does not work 'cause im user ($) and not admin (#)
>
> Wha did you expect to happen? (Expected behavior)
>
> change .sh to chmod 755 for execute bash
>
> What happened instead? (Actual behavior)
>
> nothing ._.
>
> What's different between what you expected and what actually happened?
>
> i expected a good sript in bash. now i'm sad
>
> Anything else you want to add:
>
> Please tell me what happen, maybe i'm wrong but chatGPT also no have idea why
> i cannot be admin in my own laptop xD, or maybe i need some libraries that i didnot
> install. I sell all my information so please help me to understand why does not work :)
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.42.0.windows.2
> cpu: x86_64
> built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Windows 10.0 19045
> compiler info: gnuc: 13.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
>
>
> [Enabled Hooks]
> not run from a git repository - no hooks to show
>

You don't need admin to use git on Window. OTOH Windows has no concept 
of POSIX file permissions, and this is the reason you cannot set file 
permissions using chmod under git bash.

This Stackoverflow question has the answer you're most likely looking for:

https://stackoverflow.com/questions/21691202/how-to-create-file-execute-mode-permissions-in-git-on-windows

Regards,

--

Thomas

Bugreport

[Frank Schwidom]

This bug exists in possibly all git versions.

$ git init
$ touch a.txt
$ ln -s a.txt d
$ git add .
$ git commit -m + .
[master (root-commit) f6b4468] +
 2 files changed, 1 insertion(+)
 create mode 100644 a.txt
 create mode 120000 d
$ ls -la
total 12
drwxr-xr-x 3 ox ox 4096 Jan 19 14:10 .
drwxr-xr-x 4 ox ox 4096 Jan 19 14:04 ..
drwxr-xr-x 8 ox ox 4096 Jan 19 14:10 .git
-rw-r--r-- 1 ox ox    0 Jan 19 14:10 a.txt
lrwxrwxrwx 1 ox ox    5 Jan 19 14:10 d -> a.txt
$ rm d
$ mkdir d
$ touch d/b.txt
$ git add .
$ git commit . -m +
error: 'd' does not have a commit checked out
fatal: updating files failed


# I expect that git just replaces the link by the directory. But it makes problems.

# Workaround:

$ rm -rf d
$ git add .
$ git commit -m + .
[master 522e6db] +
 1 file changed, 1 deletion(-)
 delete mode 120000 d
$ mkdir d
$ touch d/b.txt
$ git add .
$ git commit -m + .
[master 8a125ee] +
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 d/b.txt

[System Info]
git version:
git version 2.43.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.1.0-8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.25-1 (2023-04-22) x86_64
compiler info: gnuc: 13.2
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Thanks in advance,
Frank Schwidom

Re: Bugreport

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

On 2024-01-19 at 13:25:51, Frank Schwidom wrote:
> 
> This bug exists in possibly all git versions.
> 
> $ git init
> $ touch a.txt
> $ ln -s a.txt d
> $ git add .
> $ git commit -m + .
> [master (root-commit) f6b4468] +
>  2 files changed, 1 insertion(+)
>  create mode 100644 a.txt
>  create mode 120000 d
> $ ls -la
> total 12
> drwxr-xr-x 3 ox ox 4096 Jan 19 14:10 .
> drwxr-xr-x 4 ox ox 4096 Jan 19 14:04 ..
> drwxr-xr-x 8 ox ox 4096 Jan 19 14:10 .git
> -rw-r--r-- 1 ox ox    0 Jan 19 14:10 a.txt
> lrwxrwxrwx 1 ox ox    5 Jan 19 14:10 d -> a.txt
> $ rm d
> $ mkdir d
> $ touch d/b.txt
> $ git add .
> $ git commit . -m +
> error: 'd' does not have a commit checked out
> fatal: updating files failed

I can confirm this behaviour[0], and it's definitely wrong that it
thinks `d` is a submodule.  It does, however, work if you do `git commit
-m +` (that is, without the .), which makes sense since the relevant
change is already staged in the index.

I'm not going to get to a patch or more thorough investigation, but
perhaps someone else will.

[0] git version 2.43.0.381.gb435a96ce8
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Bugreport

[do Carmo Lucas, Dr. Amilcar (T-PSC)]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
Using git "difftool --dir-diff" on windows on a lfs repository

What did you expect to happen? (Expected behavior)
I expected it to call the configured tool with no errors

What happened instead? (Actual behavior)
I get the error
error: could not symlink 'D:/xxxx/KUS.a2l' to 'C:\xxxx/KUS.a2l': Function not implemented

To fix this I need to call difftool with "--no-symlinks" but the documentation mentions that "--no-symlinks" is the default on windows. Well, it clearly isn't.

What's different between what you expected and what actually happened?

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.52.0.windows.1
cpu: x86_64
built from commit: 2912d8e9b8253723974b7baf1c890273b1a1c5bd
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
libcurl: 8.17.0
OpenSSL: OpenSSL 3.5.4 30 Sep 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Windows 10.0 26100 
compiler info: gnuc: 15.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]
commit-msg
pre-commit

Mit freundlichen Grüßen,

Dr.-Ing. Amilcar Lucas


IAV – your Tech Solution Provider
Your one stop shop for the Software Defined Vehicle and all Powertrains

IAV GmbH Ingenieurgesellschaft Auto und Verkehr; Sitz/Registered Office: Berlin; Registergericht/Registration Court: Amtsgericht Charlottenburg (Berlin); Registernummer/Company Registration Number: HRB 21 280 B; Geschäftsführer/Managing Directors: Joerg Astalosch, Dr. Frauke Esser, Jens Pfitzinger; Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Nikolai Ardey